draft-ietf-ipp-model-11.txt   rfc2566.txt 
INTERNET-DRAFT Network Working Group R. deBry
draft-ietf-ipp-model-11.txt Request for Comments: 2566 Utah Valley State College
R. deBry Category: Experimental T. Hastings
IBM Corporation
T. Hastings
Xerox Corporation Xerox Corporation
R. Herriot R. Herriot
Sun Microsystems Xerox Corporation
S. Isaacson S. Isaacson
Novell, Inc. Novell, Inc.
P. Powell P. Powell
Astart Technologies Astart Technologies
November 16, 1998 April 1999
Internet Printing Protocol/1.0: Model and Semantics Internet Printing Protocol/1.0: Model and Semantics
Copyright (C) The Internet Society (date). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This memo defines an Experimental Protocol for the Internet
documents of the Internet Engineering Task Force (IETF), its areas, and community. It does not specify an Internet standard of any kind.
its working groups. Note that other groups may also distribute working Discussion and suggestions for improvement are requested.
documents as Internet-Drafts. Distribution of this memo is unlimited.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress".
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document describes a
simplified model consisting of abstract objects, their attributes, and
their operations that is independent of encoding and transport. The
model consists of a Printer and a Job object. A Job optionally supports
multiple documents. IPP 1.0 semantics allow end-users and operators to
query printer capabilities, submit print jobs, inquire about the status
of print jobs and printers, and cancel print jobs. This document also
addresses security, internationalization, and directory issues.
Isaacson, Powell Expires May 16, 1999
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT]
Internet Printing Protocol/1.0: Model and Semantics (this document)
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [IPP LPD]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that are
satisfied in IPP/1.0. Operator and administrator requirements are out
of scope for version 1.0.
The "Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol" document describes IPP from a high level view,
defines a roadmap for the various documents that form the suite of IPP
specifications, and gives background and rationale for the IETF working
group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is
a formal mapping of the abstract operations and attributes defined in
the model document onto HTTP/1.1. It defines the encoding rules for a
new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives
insight and advice to implementers of IPP clients and IPP objects. It
is intended to help them understand IPP/1.0 and some of the
considerations that may assist them in the design of their client and/or
IPP object implementations. For example, a typical order of processing
requests is given, including error checking. Motivation for some of the
specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice
to implementers of gateways between IPP and LPD (Line Printer Daemon)
implementations.
Isaacson, Powell Expires May 16, 1999
Table of Contents
1. Introduction 7
1.1 Simplified Printing Model 8
2. IPP Objects 11
2.1 Printer Object 11
2.2 Job Object 13
2.3 Object Relationships 14
2.4 Object Identity 15
3. IPP Operations 17
3.1 Common Semantics 18
3.1.1 Required Parameters 18
3.1.2 Operation IDs and Request IDs 19
3.1.3 Attributes 19
3.1.4 Character Set and Natural Language Operation Attributes 21
3.1.4.1 Request Operation Attributes 21
3.1.4.2 Response Operation Attributes 24
3.1.5 Operation Targets 25
3.1.6 Operation Status Codes and Messages 27
3.1.7 Versions 28
3.1.8 Job Creation Operations 29
3.2 Printer Operations 31
3.2.1 Print-Job Operation 31
3.2.1.1 Print-Job Request 31
3.2.1.2 Print-Job Response 35
3.2.2 Print-URI Operation 37
3.2.3 Validate-Job Operation 38
3.2.4 Create-Job Operation 38
3.2.5 Get-Printer-Attributes Operation 39
3.2.5.1 Get-Printer-Attributes Request 39
3.2.5.2 Get-Printer-Attributes Response 41
3.2.6 Get-Jobs Operation 42
3.2.6.1 Get-Jobs Request 42
3.2.6.2 Get-Jobs Response 43
3.3 Job Operations 45
3.3.1 Send-Document Operation 45
3.3.1.1 Send-Document Request 46
3.3.1.2 Send-Document Response 47
3.3.2 Send-URI Operation 48
3.3.3 Cancel-Job Operation 48
3.3.3.1 Cancel-Job Request 49
3.3.3.2 Cancel-Job Response 49
3.3.4 Get-Job-Attributes Operation 50
3.3.4.1 Get-Job-Attributes Request 51
3.3.4.2 Get-Job-Attributes Response 51
4. Object Attributes 52
4.1 Attribute Syntaxes 52
4.1.1 'text' 53
4.1.1.1 'textWithoutLanguage' 54
4.1.1.2 'textWithLanguage' 54
Isaacson, Powell Expires May 16, 1999
4.1.2 'name' 55
4.1.2.1 'nameWithoutLanguage' 55
4.1.2.2 'nameWithLanguage' 56
4.1.3 'keyword' 56
4.1.4 'enum' 57
4.1.5 'uri' 58
4.1.6 'uriScheme' 58
4.1.7 'charset' 58
4.1.8 'naturalLanguage' 59
4.1.9 'mimeMediaType' 60
4.1.10 'octetString' 61
4.1.11 'boolean' 61
4.1.12 'integer' 61
4.1.13 'rangeOfInteger' 61
4.1.14 'dateTime' 61
4.1.15 'resolution' 62
4.1.16 '1setOf X' 62
4.2 Job Template Attributes 62
4.2.1 job-priority (integer(1:100)) 66
4.2.2 job-hold-until (type3 keyword | name (MAX)) 67
4.2.3 job-sheets (type3 keyword | name(MAX)) 67
4.2.4 multiple-document-handling (type2 keyword) 68
4.2.5 copies (integer(1:MAX)) 69
4.2.6 finishings (1setOf type2 enum) 69
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 70
4.2.8 sides (type2 keyword) 71
4.2.9 number-up (integer(1:MAX)) 72
4.2.10 orientation-requested (type2 enum) 72
4.2.11 media (type3 keyword | name(MAX)) 73
4.2.12 printer-resolution (resolution) 74
4.2.13 print-quality (type2 enum) 74
4.3 Job Description Attributes 74
4.3.1 job-uri (uri) 76
4.3.2 job-id (integer(1:MAX)) 76
4.3.3 job-printer-uri (uri) 76
4.3.4 job-more-info (uri) 76
4.3.5 job-name (name(MAX)) 77
4.3.6 job-originating-user-name (name(MAX)) 77
4.3.7 job-state (type1 enum) 77
4.3.8 job-state-reasons (1setOf type2 keyword) 80
4.3.9 job-state-message (text(MAX)) 82
4.3.10 number-of-documents (integer(0:MAX)) 82
4.3.11 output-device-assigned (name(127)) 82
4.3.12 time-at-creation (integer(0:MAX)) 83
4.3.13 time-at-processing (integer(0:MAX)) 83
4.3.14 time-at-completed (integer(0:MAX)) 83
4.3.15 number-of-intervening-jobs (integer(0:MAX)) 83
4.3.16 job-message-from-operator (text(127)) 83
4.3.17 job-k-octets (integer(0:MAX)) 83
4.3.18 job-impressions (integer(0:MAX)) 84
4.3.19 job-media-sheets (integer(0:MAX)) 84
4.3.20 job-k-octets-processed (integer(0:MAX)) 85
4.3.21 job-impressions-completed (integer(0:MAX)) 85
4.3.22 job-media-sheets-completed (integer(0:MAX)) 85
Isaacson, Powell Expires May 16, 1999
4.3.23 attributes-charset (charset) 86
4.3.24 attributes-natural-language (naturalLanguage) 86
4.4 Printer Description Attributes 86
4.4.1 printer-uri-supported (1setOf uri) 88
4.4.2 uri-security-supported (1setOf type2 keyword) 88
4.4.3 printer-name (name(127)) 89
4.4.4 printer-location (text(127)) 90
4.4.5 printer-info (text(127)) 90
4.4.6 printer-more-info (uri) 90
4.4.7 printer-driver-installer (uri) 90
4.4.8 printer-make-and-model (text(127)) 90
4.4.9 printer-more-info-manufacturer (uri) 90
4.4.10 printer-state (type1 enum) 91
4.4.11 printer-state-reasons (1setOf type2 keyword) 92
4.4.12 printer-state-message (text(MAX)) 94
4.4.13 operations-supported (1setOf type2 enum) 94
4.4.14 charset-configured (charset) 95
4.4.15 charset-supported (1setOf charset) 95
4.4.16 natural-language-configured (naturalLanguage) 95
4.4.17 generated-natural-language-supported(1setOf naturalLanguage)95
4.4.18 document-format-default (mimeMediaType) 96
4.4.19 document-format-supported (1setOf mimeMediaType) 96
4.4.20 printer-is-accepting-jobs (boolean) 96
4.4.21 queued-job-count (integer(0:MAX)) 97
4.4.22 printer-message-from-operator (text(127)) 97
4.4.23 color-supported (boolean) 97
4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 97
4.4.25 pdl-override-supported (type2 keyword) 97
4.4.26 printer-up-time (integer(1:MAX)) 98
4.4.27 printer-current-time (dateTime) 98
4.4.28 multiple-operation-time-out (integer(1:MAX)) 98
4.4.29 compression-supported (1setOf type3 keyword) 99
4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 99
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 99
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 99
5. Conformance 99
5.1 Client Conformance Requirements 100
5.2 IPP Object Conformance Requirements 100
5.2.1 Objects 101
5.2.2 Operations 101
5.2.3 IPP Object Attributes 101
5.2.4 Extensions 102
5.2.5 Attribute Syntaxes 102
5.3 Charset and Natural Language Requirements 102
5.4 Security Conformance Requirements 102
6. IANA Considerations (registered and private extensions) 103 Copyright Notice
6.1 Typed 'keyword' and 'enum' Extensions 103
6.2 Attribute Extensibility 105
6.3 Attribute Syntax Extensibility 106
6.4 Operation Extensibility 106
6.5 Attribute Groups 106
6.6 Status Code Extensibility 107
Isaacson, Powell Expires May 16, 1999 Copyright (C) The Internet Society (1999). All Rights Reserved.
6.7 Registration of MIME types/sub-types for document-formats 107
6.8 Registration of charsets for use in 'charset' attribute values107
7. Internationalization Considerations 108 IESG Note
8. Security Considerations 110 This document defines an Experimental protocol for the Internet
8.1 Security Scenarios 112 community. The IESG expects that a revised version of this protocol
8.1.1 Client and Server in the Same Security Domain 112 will be published as Proposed Standard protocol. The Proposed
8.1.2 Client and Server in Different Security Domains 112 Standard, when published, is expected to change from the protocol
8.1.3 Print by Reference 112 defined in this memo. In particular, it is expected that the
8.2 URIs for SSL3 and non-SSL3 Access 112 standards-track version of the protocol will incorporate strong
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 113 authentication and privacy features, and that an "ipp:" URL type will
8.4 Restricted Queries 114 be defined which supports those security measures. Other changes to
8.5 Queries on jobs submitted using non-IPP protocols 115 the protocol are also possible. Implementors are warned that future
8.6 IPP Security Application Profile for SSL3 115 versions of this protocol may not interoperate with the version of
IPP defined in this document, or if they do interoperate, that some
protocol features may not be available.
9. References 116 The IESG encourages experimentation with this protocol, especially in
combination with Transport Layer Security (TLS) [RFC 2246], to help
determine how TLS may effectively be used as a security layer for
IPP.
10.Copyright Notice 119 Abstract
11.Author's Address 119 This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document describes a
simplified model consisting of abstract objects, their attributes,
and their operations that is independent of encoding and transport.
The model consists of a Printer and a Job object. A Job optionally
supports multiple documents. IPP 1.0 semantics allow end-users and
operators to query printer capabilities, submit print jobs, inquire
about the status of print jobs and printers, and cancel print jobs.
This document also addresses security, internationalization, and
directory issues.
12.Formats for IPP Registration Proposals 122 The full set of IPP documents includes:
12.1 Type2 keyword attribute values registration 122
12.2 Type3 keyword attribute values registration 122
12.3 Type2 enum attribute values registration 122
12.4 Type3 enum attribute values registration 123
12.5 Attribute registration 123
12.6 Attribute Syntax registration 124
12.7 Operation registration 124
12.8 Attribute Group registration 116
12.9 Status code registration 124
13.APPENDIX A: Terminology 125 Design Goals for an Internet Printing Protocol [RFC2567]
13.1 Conformance Terminology 125 Rationale for the Structure and Model and Protocol for the Internet
13.1.1 NEED NOT 125 Printing Protocol [RFC2568]
13.2 Model Terminology 125 Internet Printing Protocol/1.0: Model and Semantics (this document)
13.2.1 Keyword 125 Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
13.2.2 Attributes 125 Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
13.2.2.1 Attribute Name 126 Mapping between LPD and IPP Protocols [RFC2569]
13.2.2.2 Attribute Group Name 126
13.2.2.3 Attribute Value 126
13.2.2.4 Attribute Syntax 126
13.2.3 Supports 126
13.2.4 print-stream page 128
13.2.5 impression 128
14.APPENDIX B: Status Codes and Suggested Status Code Messages 128 The "Design Goals for an Internet Printing Protocol" document takes a
14.1 Status Codes 129 broad look at distributed printing functionality, and it enumerates
14.1.1 Informational 130 real-life scenarios that help to clarify the features that need to be
14.1.2 Successful Status Codes 130 included in a printing protocol for the Internet. It identifies
14.1.2.1 successful-ok (0x0000) 130 requirements for three types of users: end users, operators, and
14.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001)130 administrators. It calls out a subset of end user requirements that
14.1.2.3 successful-ok-conflicting-attributes (0x0002) 130 are satisfied in IPP/1.0. Operator and administrator requirements
are out of scope for version 1.0.
Isaacson, Powell Expires May 16, 1999 The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specifications, and gives background and rationale for the
IETF working group's major decisions.
14.1.3 Redirection Status Codes 131 The "Internet Printing Protocol/1.0: Encoding and Transport" document
14.1.4 Client Error Status Codes 131 is a formal mapping of the abstract operations and attributes defined
14.1.4.1 client-error-bad-request (0x0400) 131 in the model document onto HTTP/1.1. It defines the encoding rules
14.1.4.2 client-error-forbidden (0x0401) 131 for a new Internet media type called "application/ipp".
14.1.4.3 client-error-not-authenticated (0x0402) 131
14.1.4.4 client-error-not-authorized (0x0403) 131
14.1.4.5 client-error-not-possible (0x0404) 132
14.1.4.6 client-error-timeout (0x0405) 132
14.1.4.7 client-error-not-found (0x0406) 132
14.1.4.8 client-error-gone (0x0407) 132
14.1.4.9 client-error-request-entity-too-large (0x0408) 133
14.1.4.10client-error-request-value-too-long (0x0409) 133
14.1.4.11client-error-document-format-not-supported (0x040A) 133
14.1.4.12client-error-attributes-or-values-not-supported (0x040B)133
14.1.4.13client-error-uri-scheme-not-supported (0x040C) 134
14.1.4.14client-error-charset-not-supported (0x040D) 134
14.1.4.15client-error-conflicting-attributes (0x040E) 134
14.1.5 Server Error Status Codes 134
14.1.5.1 server-error-internal-error (0x0500) 134
14.1.5.2 server-error-operation-not-supported (0x0501) 135
14.1.5.3 server-error-service-unavailable (0x0502) 135
14.1.5.4 server-error-version-not-supported (0x0503) 135
14.1.5.5 server-error-device-error (0x0504) 135
14.1.5.6 server-error-temporary-error (0x0505) 136
14.1.5.7 server-error-not-accepting-jobs (0x0506) 136
14.1.5.8 server-error-busy (0x0507) 136
14.1.5.9 server-error-job-canceled (0x0508) 136
14.2 Status Codes for IPP Operations 137
15.APPENDIX C: "media" keyword values 137 The "Internet Printing Protocol/1.0: Implementer's Guide" document
gives insight and advice to implementers of IPP clients and IPP
objects. It is intended to help them understand IPP/1.0 and some of
the considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
16.APPENDIX D: Processing IPP Attributes 141 The "Mapping between LPD and IPP Protocols" document gives some
16.1 Fidelity 142 advice to implementers of gateways between IPP and LPD (Line Printer
16.2 Page Description Language (PDL) Override 143 Daemon) implementations.
16.3 Using Job Template Attributes During Document Processing. 145
17.APPENDIX E: Generic Directory Schema 146 Table of Contents
18.APPENDIX F: Change History for the Model and Semantics document 147 1. Introduction 8
1.1 Simplified Printing Model 9
2. IPP Objects 11
2.1 Printer Object 12
2.2 Job Object 14
2.3 Object Relationships 14
2.4 Object Identity 15
3. IPP Operations 18
3.1 Common Semantics 19
3.1.1 Required Parameters 19
3.1.2 Operation IDs and Request IDs 20
3.1.3 Attributes 20
3.1.4 Character Set and Natural Language Operation Attributes 22
3.1.4.1 Request Operation Attributes 22
3.1.4.2 Response Operation Attributes 26
3.1.5 Operation Targets 28
3.1.6 Operation Status Codes and Messages 29
3.1.7 Versions 30
3.1.8 Job Creation Operations 32
3.2 Printer Operations 34
3.2.1 Print-Job Operation 34
3.2.1.1 Print-Job Request 34
3.2.1.2 Print-Job Response 38
3.2.2 Print-URI Operation 41
3.2.3 Validate-Job Operation 42
3.2.4 Create-Job Operation 42
3.2.5 Get-Printer-Attributes Operation 43
3.2.5.1 Get-Printer-Attributes Request 44
3.2.5.2 Get-Printer-Attributes Response 46
3.2.6 Get-Jobs Operation 47
3.2.6.1 Get-Jobs Request 47
3.2.6.2 Get-Jobs Response 49
3.3 Job Operations 50
3.3.1 Send-Document Operation 50
3.3.1.1 Send-Document Request 51
3.3.1.2 Send-Document Response 53
3.3.2 Send-URI Operation 54
3.3.3 Cancel-Job Operation 54
3.3.3.1 Cancel-Job Request 54
3.3.3.2 Cancel-Job Response 55
3.3.4 Get-Job-Attributes Operation 56
3.3.4.1 Get-Job-Attributes Request 57
3.3.4.2 Get-Job-Attributes Response 57
4. Object Attributes 58
4.1 Attribute Syntaxes 59
4.1.1 'text' 60
4.1.1.1 'textWithoutLanguage' 61
4.1.1.2 'textWithLanguage' 61
4.1.2 'name' 62
4.1.2.1 'nameWithoutLanguage' 62
4.1.2.2 'nameWithLanguage' 63
4.1.2.3 Matching 'name' attribute values 63
4.1.3 'keyword' 64
4.1.4 'enum' 65
4.1.5 'uri' 65
4.1.6 'uriScheme' 65
4.1.7 'charset' 66
4.1.8 'naturalLanguage' 67
4.1.9 'mimeMediaType' 67
4.1.10 'octetString' 69
4.1.11 'boolean' 69
4.1.12 'integer' 69
4.1.13 'rangeOfInteger' 69
4.1.14 'dateTime' 69
4.1.15 'resolution' 69
4.1.16 '1setOf X' 70
4.2 Job Template Attributes 70
4.2.1 job-priority (integer(1:100)) 74
4.2.2 job-hold-until (type3 keyword | name (MAX)) 75
4.2.3 job-sheets (type3 keyword | name(MAX)) 75
4.2.4 multiple-document-handling (type2 keyword) 76
4.2.5 copies (integer(1:MAX)) 77
4.2.6 finishings (1setOf type2 enum) 78
4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 79
4.2.8 sides (type2 keyword) 80
4.2.9 number-up (integer(1:MAX)) 80
4.2.10 orientation-requested (type2 enum) 81
4.2.11 media (type3 keyword | name(MAX)) 82
4.2.12 printer-resolution (resolution) 83
4.2.13 print-quality (type2 enum) 83
4.3 Job Description Attributes 84
4.3.1 job-uri (uri) 85
4.3.2 job-id (integer(1:MAX)) 85
4.3.3 job-printer-uri (uri) 86
4.3.4 job-more-info (uri) 86
4.3.5 job-name (name(MAX)) 86
4.3.6 job-originating-user-name (name(MAX)) 86
4.3.7 job-state (type1 enum) 87
4.3.8 job-state-reasons (1setOf type2 keyword) 90
4.3.9 job-state-message (text(MAX)) 92
4.3.10 number-of-documents (integer(0:MAX)) 93
4.3.11 output-device-assigned (name(127)) 93
4.3.12 time-at-creation (integer(0:MAX)) 93
4.3.13 time-at-processing (integer(0:MAX)) 93
4.3.14 time-at-completed (integer(0:MAX)) 94
4.3.15 number-of-intervening-jobs (integer(0:MAX)) 94
4.3.16 job-message-from-operator (text(127)) 94
4.3.17 job-k-octets (integer(0:MAX)) 94
4.3.18 job-impressions (integer(0:MAX)) 95
4.3.19 job-media-sheets (integer(0:MAX)) 95
4.3.20 job-k-octets-processed (integer(0:MAX)) 96
4.3.21 job-impressions-completed (integer(0:MAX)) 96
4.3.22 job-media-sheets-completed (integer(0:MAX)) 96
4.3.23 attributes-charset (charset) 97
4.3.24 attributes-natural-language (naturalLanguage) 97
4.4 Printer Description Attributes 97
4.4.1 printer-uri-supported (1setOf uri) 99
4.4.2 uri-security-supported (1setOf type2 keyword) 100
4.4.3 printer-name (name(127)) 101
4.4.4 printer-location (text(127)) 101
4.4.5 printer-info (text(127)) 101
4.4.6 printer-more-info (uri) 101
4.4.7 printer-driver-installer (uri) 102
4.4.8 printer-make-and-model (text(127)) 102
4.4.9 printer-more-info-manufacturer (uri) 102
4.4.10 printer-state (type1 enum) 102
4.4.11 printer-state-reasons (1setOf type2 keyword) 103
4.4.12 printer-state-message (text(MAX)) 106
4.4.13 operations-supported (1setOf type2 enum) 106
4.4.14 charset-configured (charset) 107
4.4.15 charset-supported (1setOf charset) 107
4.4.16 natural-language-configured (naturalLanguage) 107
4.4.17 generated-natural-language-supported(1setOf naturalLanguage108
4.4.18 document-format-default (mimeMediaType) 108
4.4.19 document-format-supported (1setOf mimeMediaType) 108
4.4.20 printer-is-accepting-jobs (boolean) 109
4.4.21 queued-job-count (integer(0:MAX)) 109
4.4.22 printer-message-from-operator (text(127)) 109
4.4.23 color-supported (boolean) 109
4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 109
4.4.25 pdl-override-supported (type2 keyword) 110
4.4.26 printer-up-time (integer(1:MAX)) 110
4.4.27 printer-current-time (dateTime) 111
4.4.28 multiple-operation-time-out (integer(1:MAX)) 111
4.4.29 compression-supported (1setOf type3 keyword) 111
4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 112
4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 112
4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 112
5. Conformance 112
5.1 Client Conformance Requirements 112
5.2 IPP Object Conformance Requirements 113
5.2.1 Objects 113
5.2.2 Operations 113
5.2.3 IPP Object Attributes 114
5.2.4 Extensions 114
5.2.5 Attribute Syntaxes 115
5.3 Charset and Natural Language Requirements 115
5.4 Security Conformance Requirements 115
6. IANA Considerations (registered and private extensions) 116
6.1 Typed 'keyword' and 'enum' Extensions 116
6.2 Attribute Extensibility 119
6.3 Attribute Syntax Extensibility 119
6.4 Operation Extensibility 120
6.5 Attribute Groups 120
6.6 Status Code Extensibility 120
6.7 Registration of MIME types/sub-types for document-formats 121
6.8 Registration of charsets for use in 'charset' attribute values121
7. Internationalization Considerations 121
8. Security Considerations 125
8.1 Security Scenarios 126
8.1.1 Client and Server in the Same Security Domain 126
8.1.2 Client and Server in Different Security Domains 126
8.1.3 Print by Reference 127
8.2 URIs for SSL3 and non-SSL3 Access 127
8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 127
8.4 Restricted Queries 129
8.5 Queries on jobs submitted using non-IPP protocols 129
8.6 IPP Security Application Profile for SSL3 130
9. References 131
10. Authors' Addresses 134
11. Formats for IPP Registration Proposals 136
11.1 Type2 keyword attribute values registration 136
11.2 Type3 keyword attribute values registration 137
11.3 Type2 enum attribute values registration 137
11.4 Type3 enum attribute values registration 137
11.5 Attribute registration 138
11.6 Attribute Syntax registration 138
11.7 Operation registration 139
11.8 Attribute Group registration 139
11.9 Status code registration 139
12.APPENDIX A: Terminology 141
12.1 Conformance Terminology 141
12.1.1 NEED NOT 141
12.2 Model Terminology 141
12.2.1 Keyword 141
12.2.2 Attributes 141
12.2.2.1 Attribute Name 141
12.2.2.2 Attribute Group Name 142
12.2.2.3 Attribute Value 142
12.2.2.4 Attribute Syntax 142
12.2.3 Supports 142
12.2.4 print-stream page 144
12.2.5 impression 144
13.APPENDIX B: Status Codes and Suggested Status Code Messages 145
13.1 Status Codes 146
13.1.1 Informational 146
13.1.2 Successful Status Codes 146
13.1.2.1 successful-ok (0x0000) 146
13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146
13.1.2.3 successful-ok-conflicting-attributes (0x0002) 147
13.1.3 Redirection Status Codes 147
13.1.4 Client Error Status Codes 147
13.1.4.1 client-error-bad-request (0x0400) 147
13.1.4.2 client-error-forbidden (0x0401) 147
13.1.4.3 client-error-not-authenticated (0x0402) 148
13.1.4.4 client-error-not-authorized (0x0403) 148
13.1.4.5 client-error-not-possible (0x0404) 148
13.1.4.6 client-error-timeout (0x0405) 148
13.1.4.7 client-error-not-found (0x0406) 149
13.1.4.8 client-error-gone (0x0407) 149
13.1.4.9 client-error-request-entity-too-large (0x0408) 149
13.1.4.10client-error-request-value-too-long (0x0409) 150
13.1.4.11client-error-document-format-not-supported (0x040A) 150
13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150
13.1.4.13client-error-uri-scheme-not-supported (0x040C) 151
13.1.4.14client-error-charset-not-supported (0x040D) 151
13.1.4.15client-error-conflicting-attributes (0x040E) 151
13.1.5 Server Error Status Codes 151
13.1.5.1 server-error-internal-error (0x0500) 151
13.1.5.2 server-error-operation-not-supported (0x0501) 152
13.1.5.3 server-error-service-unavailable (0x0502) 152
13.1.5.4 server-error-version-not-supported (0x0503) 152
13.1.5.5 server-error-device-error (0x0504) 152
13.1.5.6 server-error-temporary-error (0x0505) 153
13.1.5.7 server-error-not-accepting-jobs (0x0506) 153
13.1.5.8 server-error-busy (0x0507) 153
13.1.5.9 server-error-job-canceled (0x0508) 153
13.2 Status Codes for IPP Operations 153
14.APPENDIX C: "media" keyword values 155
15.APPENDIX D: Processing IPP Attributes 160
15.1 Fidelity 160
15.2 Page Description Language (PDL) Override 161
15.3 Using Job Template Attributes During Document Processing. 163
16.APPENDIX E: Generic Directory Schema 166
17.APPENDIX F: Change History for the Model and Semantics document 168
18.FULL COPYRIGHT STATEMENT 173
1. Introduction 1. Introduction
The Internet Printing Protocol (IPP) is an application level protocol The Internet Printing Protocol (IPP) is an application level protocol
that can be used for distributed printing using Internet tools and that can be used for distributed printing using Internet tools and
technologies. IPP version 1.0 (IPP/1.0) focuses only on end user technologies. IPP version 1.0 (IPP/1.0) focuses only on end user
functionality. This document is just one of a suite of documents that functionality. This document is just one of a suite of documents
fully define IPP. The full set of IPP documents includes: that fully define IPP. The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT]
Internet Printing Protocol/1.0: Model and Semantics (this document)
Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
Isaacson, Powell Expires May 16, 1999 Design Goals for an Internet Printing Protocol [RFC2567]
Internet Printing Protocol/1.0: Implementer's Guide [IPP-IIG] Rationale for the Structure and Model and Protocol for the Internet
Mapping between LPD and IPP Protocols [IPP-LPD] Printing Protocol [RFC2568]
Internet Printing Protocol/1.0: Model and Semantics (this document)
Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC2569]
Anyone reading these documents for the first time is strongly encouraged Anyone reading these documents for the first time is strongly
to read the IPP documents in the above order. encouraged to read the IPP documents in the above order.
This document is laid out as follows: This document is laid out as follows:
- The rest of Section 1 is an introduction to the IPP simplified - The rest of Section 1 is an introduction to the IPP simplified
model for distributed printing. model for distributed printing.
- Section 2 introduces the object types covered in the model with - Section 2 introduces the object types covered in the model with
their basic behaviors, attributes, and interactions. their basic behaviors, attributes, and interactions.
- Section 3 defines the operations included in IPP/1.0. IPP - Section 3 defines the operations included in IPP/1.0. IPP
operations are synchronous, therefore, for each operation, there is operations are synchronous, therefore, for each operation, there
a both request and a response. is a both request and a response.
- Section 4 defines the attributes (and their syntaxes) that are used - Section 4 defines the attributes (and their syntaxes) that are
in the model. used in the model.
- Sections 5 - 6 summarizes the implementation conformance - Sections 5 - 6 summarizes the implementation conformance
requirements for objects that support the protocol and IANA requirements for objects that support the protocol and IANA
considerations, respectively. considerations, respectively.
- Sections 7 - 12 cover the Internationalization and Security - Sections 7 - 11 cover the Internationalization and Security
considerations as well as References, Copyright Notice, Author considerations as well as References, Author contact information,
contact information, and Formats for Registration Proposals. and Formats for Registration Proposals.
- Sections 13 - 15 are appendices that cover Terminology, Status - Sections 12 - 14 are appendices that cover Terminology, Status
Codes and Messages, and "media" keyword values. Codes and Messages, and "media" keyword values.
Note: This document uses terms such as "attributes", Note: This document uses terms such as "attributes",
"keywords", and "support". These terms have special meaning "keywords", and "support". These terms have special
and are defined in the model terminology section 13.2. meaning and are defined in the model terminology section
Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, 12.2. Capitalized terms, such as MUST, MUST NOT, REQUIRED,
SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have special meaning SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have
relating to conformance. These terms are defined in section special meaning relating to conformance. These terms are
13.1 on conformance terminology, most of which is taken from defined in section 12.1 on conformance terminology, most of
RFC 2119 [RFC2119]. which is taken from RFC 2119 [RFC2119].
- Section 16 is an appendix that helps to clarify the effects of - Section 15 is an appendix that helps to clarify the effects of
interactions between related attributes and their values. interactions between related attributes and their values.
- Section 17 is an appendix that enumerates the subset of Printer - Section 16 is an appendix that enumerates the subset of Printer
attributes that form a generic directory schema. These attributes attributes that form a generic directory schema. These
are useful when registering a Printer so that a client can find the attributes are useful when registering a Printer so that a
Printer not just by name, but by filtered searches as well. client can find the Printer not just by name, but by filtered
- Section 18 is an appendix that provides a Change History searches as well.
summarizing the clarification and changes that might affect an - Section 17 is an appendix that provides a Change History
implementation since the June 30, 1998 draft. summarizing the clarification and changes that might affect an
implementation since the June 30, 1998 draft.
1.1 Simplified Printing Model 1.1 Simplified Printing Model
In order to achieve its goal of realizing a workable printing protocol In order to achieve its goal of realizing a workable printing
for the Internet, the Internet Printing Protocol (IPP) is based on a protocol for the Internet, the Internet Printing Protocol (IPP) is
simplified printing model that abstracts the many components of real based on a simplified printing model that abstracts the many
world printing solutions. The Internet is a distributed computing components of real world printing solutions. The Internet is a
environment where requesters of print services (clients, applications, distributed computing environment where requesters of print services
printer drivers, etc.) cooperate and interact with print service (clients, applications, printer drivers, etc.) cooperate and interact
providers. This model and semantics document describes a simple, with print service providers. This model and semantics document
abstract model for IPP even though the underlying configurations may be describes a simple, abstract model for IPP even though the underlying
configurations may be complex "n-tier" client/server systems. An
Isaacson, Powell Expires May 16, 1999 important simplifying step in the IPP model is to expose only the key
complex "n-tier" client/server systems. An important simplifying step objects and interfaces required for printing. The model described in
in the IPP model is to expose only the key objects and interfaces this model document does not include features, interfaces, and
required for printing. The model described in this model document does relationships that are beyond the scope of the first version of IPP
not include features, interfaces, and relationships that are beyond the (IPP/1.0). IPP/1.0 incorporates many of the relevant ideas and
scope of the first version of IPP (IPP/1.0). IPP/1.0 incorporates many lessons learned from other specification and development efforts
of the relevant ideas and lessons learned from other specification and [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is
development efforts [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] heavily influenced by the printing model introduced in the Document
[SWP]. IPP is heavily influenced by the printing model introduced in Printing Application (DPA) [ISO10175] standard. Although DPA
the Document Printing Application (DPA) [ISO10175] standard. Although specifies both end user and administrative features, IPP version 1.0
DPA specifies both end user and administrative features, IPP version 1.0 (IPP/1.0) focuses only on end user functionality.
(IPP/1.0) focuses only on end user functionality.
The IPP/1.0 model encapsulates the important components of distributed The IPP/1.0 model encapsulates the important components of
printing into two object types: distributed printing into two object types:
- Printer (Section 2.1) - Printer (Section 2.1)
- Job (Section 2.2) - Job (Section 2.2)
Each object type has an associated set of operations (see section 3) and Each object type has an associated set of operations (see section 3)
attributes (see section 4). and attributes (see section 4).
It is important, however, to understand that in real system It is important, however, to understand that in real system
implementations (which lie underneath the abstracted IPP/1.0 model), implementations (which lie underneath the abstracted IPP/1.0 model),
there are other components of a print service which are not explicitly there are other components of a print service which are not
defined in the IPP/1.0 model. The following figure illustrates where explicitly defined in the IPP/1.0 model. The following figure
IPP/1.0 fits with respect to these other components. illustrates where IPP/1.0 fits with respect to these other
components.
Isaacson, Powell Expires May 16, 1999 +--------------+
+--------------+ | Application |
| Application | o +. . . . . . . |
o +. . . . . . . | \|/ | Spooler |
\|/ | Spooler | / \ +. . . . . . . | +---------+
/ \ +. . . . . . . | +---------+ End-User | Print Driver |---| File |
End-User | Print Driver |---| File | +-----------+ +-----+ +------+-------+ +----+----+
+-----------+ +-----+ +------+-------+ +----+----+ | Browser | | GUI | | |
| Browser | | GUI | | | +-----+-----+ +--+--+ | |
+-----+-----+ +--+--+ | | | | | |
| | | | | +---+------------+---+ |
| +---+------------+---+ | N D S | | IPP Client |------------+
N D S | | IPP Client |------------+ O I E | +---------+----------+
O I E | +---------+----------+ T R C | |
T R C | | I E U |
I E U | F C R -------------- Transport ------------------
F C R -------------- Transport ------------------ I T I
I T I C O T | --+
C O T | --+ A R Y +--------+--------+ |
A R Y +--------+--------+ | T Y | IPP Server | |
T Y | IPP Server | | I +--------+--------+ |
I +--------+--------+ | O | |
O | | N +-----------------+ | IPP Printer
N +-----------------+ | IPP Printer | Print Service | |
| Print Service | | +-----------------+ |
+-----------------+ | | --+
| --+ +-----------------+
+-----------------+ | Output Device(s)|
| Output Device(s)| +-----------------+
+-----------------+
An IPP Printer object encapsulates the functions normally associated An IPP Printer object encapsulates the functions normally associated
with physical output devices along with the spooling, scheduling and with physical output devices along with the spooling, scheduling and
multiple device management functions often associated with a print multiple device management functions often associated with a print
server. Printer objects are optionally registered as entries in a server. Printer objects are optionally registered as entries in a
directory where end users find and select them based on some sort of directory where end users find and select them based on some sort of
filtered and context based searching mechanism (see section 17). The filtered and context based searching mechanism (see section 16). The
directory is used to store relatively static information about the directory is used to store relatively static information about the
Printer, allowing end users to search for and find Printers that match Printer, allowing end users to search for and find Printers that
their search criteria, for example: name, context, printer capabilities, match their search criteria, for example: name, context, printer
etc. The more dynamic information, such as state, currently loaded and capabilities, etc. The more dynamic information, such as state,
ready media, number of jobs at the Printer, errors, warnings, and so currently loaded and ready media, number of jobs at the Printer,
forth, is directly associated with the Printer object itself rather than errors, warnings, and so forth, is directly associated with the
with the entry in the directory which only represents the Printer Printer object itself rather than with the entry in the directory
object. which only represents the Printer object.
IPP clients implement the IPP protocol on the client side and give end IPP clients implement the IPP protocol on the client side and give
users (or programs running on behalf of end users) the ability to query end users (or programs running on behalf of end users) the ability to
Printer objects and submit and manage print jobs. An IPP server is just query Printer objects and submit and manage print jobs. An IPP
that part of the Printer object that implements the server-side server is just that part of the Printer object that implements the
protocol. The rest of the Printer object implements (or gateways into) server-side protocol. The rest of the Printer object implements (or
the application semantics of the print service itself. The Printer gateways into) the application semantics of the print service itself.
objects may be embedded in an output device or may be implemented on a The Printer objects may be embedded in an output device or may be
host on the network that communicates with an output device. implemented on a host on the network that communicates with an output
device.
Isaacson, Powell Expires May 16, 1999 When a job is submitted to the Printer object and the Printer object
When a job is submitted to the Printer object and the Printer object validates the attributes in the submission request, the Printer
validates the attributes in the submission request, the Printer object object creates a new Job object. The end user then interacts with
creates a new Job object. The end user then interacts with this new Job this new Job object to query its status and monitor the progress of
object to query its status and monitor the progress of the job. End the job. End users may also cancel the print job by using the Job
users may also cancel the print job by using the Job object's Cancel-Job object's Cancel-Job operation. The notification service is out of
operation. The notification service is out of scope for IPP/1.0, but scope for IPP/1.0, but using such a notification service, the end
using such a notification service, the end user is able to register for user is able to register for and receive Printer specific and Job
and receive Printer specific and Job specific events. An end user can specific events. An end user can query the status of Printer objects
query the status of Printer objects and can follow the progress of Job and can follow the progress of Job objects by polling using the Get-
objects by polling using the Get-Printer-Attributes, Get-Jobs, and Get- Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations.
Job-Attributes operations.
2. IPP Objects 2. IPP Objects
The IPP/1.0 model introduces objects of type Printer and Job. Each type The IPP/1.0 model introduces objects of type Printer and Job. Each
of object models relevant aspects of a real-world entity such as a real type of object models relevant aspects of a real-world entity such as
printer or real print job. Each object type is defined as a set of a real printer or real print job. Each object type is defined as a
possible attributes that may be supported by instances of that object set of possible attributes that may be supported by instances of that
type. For each object (instance), the actual set of supported object type. For each object (instance), the actual set of supported
attributes and values describe a specific implementation. The object's attributes and values describe a specific implementation. The
attributes and values describe its state, capabilities, realizable object's attributes and values describe its state, capabilities,
features, job processing functions, and default behaviors and realizable features, job processing functions, and default behaviors
characteristics. For example, the Printer object type is defined as a and characteristics. For example, the Printer object type is defined
set of attributes that each Printer object potentially supports. In the as a set of attributes that each Printer object potentially supports.
same manner, the Job object type is defined as a set of attributes that In the same manner, the Job object type is defined as a set of
are potentially supported by each Job object. attributes that are potentially supported by each Job object.
Each attribute included in the set of attributes defining an object type Each attribute included in the set of attributes defining an object
is labeled as: type is labeled as:
- "REQUIRED": each object MUST support the attribute. - "REQUIRED": each object MUST support the attribute.
- "OPTIONAL": each object MAY support the attribute. - "OPTIONAL": each object MAY support the attribute.
There is no such similar labeling of attribute values. However, if an There is no such similar labeling of attribute values. However, if
implementation supports an attribute, it MUST support at least one of an implementation supports an attribute, it MUST support at least one
the possible values for that attribute. of the possible values for that attribute.
2.1 Printer Object 2.1 Printer Object
The major component of the IPP/1.0 model is the Printer object. A The major component of the IPP/1.0 model is the Printer object. A
Printer object implements the server-side of the IPP/1.0 protocol. Printer object implements the server-side of the IPP/1.0 protocol.
Using the protocol, end users may query the attributes of the Printer Using the protocol, end users may query the attributes of the Printer
object and submit print jobs to the Printer object. The actual object and submit print jobs to the Printer object. The actual
implementation components behind the Printer abstraction may take on implementation components behind the Printer abstraction may take on
different forms and different configurations. However, the model different forms and different configurations. However, the model
abstraction allows the details of the configuration of real components abstraction allows the details of the configuration of real
to remain opaque to the end user. Section 3 describes each of the components to remain opaque to the end user. Section 3 describes
Printer operations in detail. each of the Printer operations in detail.
The capabilities and state of a Printer object are described by its The capabilities and state of a Printer object are described by its
attributes. Printer attributes are divided into two groups: attributes. Printer attributes are divided into two groups:
Isaacson, Powell Expires May 16, 1999 - "job-template" attributes: These attributes describe supported
- "job-template" attributes: These attributes describe supported job job processing capabilities and defaults for the Printer object.
processing capabilities and defaults for the Printer object. (See (See section 4.2)
section 4.2) - "printer-description" attributes: These attributes describe the
- "printer-description" attributes: These attributes describe the Printer object's identification, state, location, references to
Printer object's identification, state, location, references to other sources of information about the Printer object, etc. (see
other sources of information about the Printer object, etc. (see section 4.4)
section 4.4)
Since a Printer object is an abstraction of a generic document output Since a Printer object is an abstraction of a generic document output
device and print service provider, a Printer object could be used to device and print service provider, a Printer object could be used to
represent any real or virtual device with semantics consistent with the represent any real or virtual device with semantics consistent with
Printer object, such as a fax device, an imager, or even a CD writer. the Printer object, such as a fax device, an imager, or even a CD
writer.
Some examples of configurations supporting a Printer object include: Some examples of configurations supporting a Printer object include:
1) An output device with no spooling capabilities 1) An output device with no spooling capabilities
2) An output device with a built-in spooler 2) An output device with a built-in spooler
3) A print server supporting IPP with one or more associated output 3) A print server supporting IPP with one or more associated output
devices devices
3a) The associated output devices may or may not be capable of 3a) The associated output devices may or may not be capable of
spooling jobs spooling jobs
3b) The associated output devices may or may not support IPP 3b) The associated output devices may or may not support IPP
The following figures show some examples of how Printer objects can be The following figures show some examples of how Printer objects can
realized on top of various distributed printing configurations. The be realized on top of various distributed printing configurations.
embedded case below represents configurations 1 and 2. The hosted and The embedded case below represents configurations 1 and 2. The hosted
fan-out figures below represent configurations 3a and 3b. and fan-out figures below represent configurations 3a and 3b.
Isaacson, Powell Expires May 16, 1999 Legend:
Legend:
##### indicates a Printer object which is ##### indicates a Printer object which is
either embedded in an output device or is either embedded in an output device or is
hosted in a server. The Printer object hosted in a server. The Printer object
might or might not be capable of queuing/spooling. might or might not be capable of queuing/spooling.
any indicates any network protocol or direct any indicates any network protocol or direct
connect, including IPP connect, including IPP
embedded printer: embedded printer:
output device output device
+---------------+ +---------------+
O +--------+ | ########### | O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # | /|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # | / \ +--------+ | # Object # |
| ########### | | ########### |
+---------------+ +---------------+
hosted printer: hosted printer:
+---------------+ +---------------+
O +--------+ ########### | | O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device | /|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ # Object # | | / \ +--------+ # Object # | |
########### +---------------+ ########### +---------------+
+---------------+ +---------------+
fan out: | | fan out: | |
+-->| output device | +-->| output device |
any/ | | any/ | |
O +--------+ ########### / +---------------+ O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #--* /|\ | client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+ / \ +--------+ # Object # \ +---------------+
########### any\ | | ########### any\ | |
+-->| output device | +-->| output device |
| | | |
+---------------+ +---------------+
2.2 Job Object 2.2 Job Object
A Job object is used to model a print job. A Job object contains A Job object is used to model a print job. A Job object contains
documents. The information required to create a Job object is sent in a documents. The information required to create a Job object is sent
create request from the end user via an IPP Client to the Printer in a create request from the end user via an IPP Client to the
object. The Printer object validates the create request, and if the Printer object. The Printer object validates the create request, and
Printer object accepts the request, the Printer object creates the new if the Printer object accepts the request, the Printer object creates
Job object. Section 3 describes each of the Job operations in detail. the new Job object. Section 3 describes each of the Job operations
in detail.
Isaacson, Powell Expires May 16, 1999 The characteristics and state of a Job object are described by its
The characteristics and state of a Job object are described by its attributes. Job attributes are grouped into two groups as follows:
attributes. Job attributes are grouped into two groups as follows:
- "job-template" attributes: These attributes can be supplied by the - "job-template" attributes: These attributes can be supplied by
client or end user and include job processing instructions which the client or end user and include job processing instructions
are intended to override any Printer object defaults and/or which are intended to override any Printer object defaults and/or
instructions embedded within the document data. (See section 4.2) instructions embedded within the document data. (See section 4.2)
- "job-description" attributes: These attributes describe the Job - "job-description" attributes: These attributes describe the Job
object's identification, state, size, etc. The client supplies some object's identification, state, size, etc. The client supplies
of these attributes, and the Printer object generates others. (See some of these attributes, and the Printer object generates others.
section 4.3) (See section 4.3)
An implementation MUST support at least one document per Job object. An An implementation MUST support at least one document per Job object.
implementation MAY support multiple documents per Job object. A An implementation MAY support multiple documents per Job object. A
document is either: document is either:
- a stream of document data in a format supported by the Printer - a stream of document data in a format supported by the Printer
object (typically a Page Description Language - PDL), or object (typically a Page Description Language - PDL), or
- a reference to such a stream of document data - a reference to such a stream of document data
In IPP/1.0, a document is not modeled as an IPP object, therefore it has In IPP/1.0, a document is not modeled as an IPP object, therefore it
no object identifier or associated attributes. All job processing has no object identifier or associated attributes. All job
instructions are modeled as Job object attributes. These attributes are processing instructions are modeled as Job object attributes. These
called Job Template attributes and they apply equally to all documents attributes are called Job Template attributes and they apply equally
within a Job object. to all documents within a Job object.
2.3 Object Relationships 2.3 Object Relationships
IPP objects have relationships that are maintained persistently along IPP objects have relationships that are maintained persistently along
with the persistent storage of the object attributes. with the persistent storage of the object attributes.
A Printer object can represent either one or more physical output A Printer object can represent either one or more physical output
devices or a logical device which "processes" jobs but never actually devices or a logical device which "processes" jobs but never actually
uses a physical output device to put marks on paper. Examples of uses a physical output device to put marks on paper. Examples of
logical devices include a Web page publisher or a gateway into an online logical devices include a Web page publisher or a gateway into an
document archive or repository. A Printer object contains zero or more online document archive or repository. A Printer object contains
Job objects. zero or more Job objects.
A Job object is contained by exactly one Printer object, however the A Job object is contained by exactly one Printer object, however the
identical document data associated with a Job object could be sent to identical document data associated with a Job object could be sent to
either the same or a different Printer object. In this case, a second either the same or a different Printer object. In this case, a
Job object would be created which would be almost identical to the first second Job object would be created which would be almost identical to
Job object, however it would have new (different) Job object identifiers the first Job object, however it would have new (different) Job
(see section 2.4). object identifiers (see section 2.4).
A Job object is either empty (before any documents have been added) or A Job object is either empty (before any documents have been added)
contains one or more documents. If the contained document is a stream or contains one or more documents. If the contained document is a
of document data, that stream can be contained in only one document. stream of document data, that stream can be contained in only one
However, there can be identical copies of the stream in other documents document. However, there can be identical copies of the stream in
in the same or different Job objects. If the contained document is just other documents in the same or different Job objects. If the
a reference to a stream of document data, other documents (in the same contained document is just a reference to a stream of document data,
or different Job object(s)) may contain the same reference. other documents (in the same or different Job object(s)) may contain
the same reference.
Isaacson, Powell Expires May 16, 1999
2.4 Object Identity 2.4 Object Identity
All Printer and Job objects are identified by a Uniform Resource All Printer and Job objects are identified by a Uniform Resource
Identifier (URI) [RFC2396] so that they can be persistently and Identifier (URI) [RFC2396] so that they can be persistently and
unambiguously referenced. The notion of a URI is a useful concept, unambiguously referenced. The notion of a URI is a useful concept,
however, until the notion of URI is more stable (i.e., defined more however, until the notion of URI is more stable (i.e., defined more
completely and deployed more widely), it is expected that the URIs used completely and deployed more widely), it is expected that the URIs
for IPP objects will actually be URLs [RFC2396]. Since every URL is a used for IPP objects will actually be URLs [RFC2396]. Since every
specialized form of a URI, even though the more generic term URI is used URL is a specialized form of a URI, even though the more generic term
throughout the rest of this document, its usage is intended to cover the URI is used throughout the rest of this document, its usage is
more specific notion of URL as well. intended to cover the more specific notion of URL as well.
An administrator configures Printer objects to either support or not
support authentication and/or message privacy using SSL3 [SSL] (the
mechanism for security configuration is outside the scope of IPP/1.0).
In some situations, both types of connections (both authenticated and
unauthenticated) can be established using a single communication channel
that has some sort of negotiation mechanism. In other situations,
multiple communication channels are used, one for each type of security
configuration. Section 8 provides a full description of all security
considerations and configurations.
If a Printer object supports more than one communication channel, some An administrator configures Printer objects to either support or not
or all of those channels might support and/or require different security support authentication and/or message privacy using SSL3 [SSL] (the
mechanisms. In such cases, an administrator could expose the mechanism for security configuration is outside the scope of
simultaneous support for these multiple communication channels as IPP/1.0). In some situations, both types of connections (both
multiple URIs for a single Printer object where each URI represents one authenticated and unauthenticated) can be established using a single
of the communication channels to the Printer object. To support this communication channel that has some sort of negotiation mechanism.
flexibility, the IPP Printer object type defines a multi-valued In other situations, multiple communication channels are used, one
identification attribute called the "printer-uri-supported" attribute. for each type of security configuration. Section 8 provides a full
It MUST contain at least one URI. It MAY contain more than one URI. description of all security considerations and configurations.
That is, every Printer object will have at least one URI that identifies
at least one communication channel to the Printer object, but it may
have more than one URI where each URI identifies a different
communication channel to the Printer object. The "printer-uri-
supported" attribute has a companion attribute, the "uri-security-
supported" attribute, that has the same cardinality as "printer-uri-
supported". The purpose of the "uri-security-supported" attribute is to
indicate the security mechanisms (if any) used for each URI listed in
"printer-uri-supported". These two attributes are fully described in
sections 4.4.1 and 4.4.2.
When a job is submitted to the Printer object via a create request, the If a Printer object supports more than one communication channel,
client supplies only a single Printer object URI. The client supplied some or all of those channels might support and/or require different
Printer object URI MUST be one of the values in the "printer-uri- security mechanisms. In such cases, an administrator could expose
supported" Printer attribute. the simultaneous support for these multiple communication channels as
multiple URIs for a single Printer object where each URI represents
one of the communication channels to the Printer object. To support
this flexibility, the IPP Printer object type defines a multi-valued
identification attribute called the "printer-uri-supported"
attribute. It MUST contain at least one URI. It MAY contain more
than one URI. That is, every Printer object will have at least one
URI that identifies at least one communication channel to the Printer
object, but it may have more than one URI where each URI identifies a
different communication channel to the Printer object. The
"printer-uri-supported" attribute has a companion attribute, the
"uri-security-supported" attribute, that has the same cardinality as
"printer-uri-supported". The purpose of the "uri-security-supported"
attribute is to indicate the security mechanisms (if any) used for
each URI listed in "printer-uri-supported". These two attributes are
fully described in sections 4.4.1 and 4.4.2.
Note: IPP/1.0 does not specify how the client obtains the client When a job is submitted to the Printer object via a create request,
supplied URI, but it is RECOMMENDED that a Printer object be registered the client supplies only a single Printer object URI. The client
as an entry in a directory service. End-users and programs can then supplied Printer object URI MUST be one of the values in the
interrogate the directory searching for Printers. Section 17 defines a "printer-uri-supported" Printer attribute.
generic schema for Printer object entries in the directory service and
describes how the entry acts as a bridge to the actual IPP Printer
object. The entry in the directory that represents the IPP Printer
Isaacson, Powell Expires May 16, 1999 Note: IPP/1.0 does not specify how the client obtains the client
object includes the possibly many URIs for that Printer object as values supplied URI, but it is RECOMMENDED that a Printer object be
in one its attributes. registered as an entry in a directory service. End-users and
programs can then interrogate the directory searching for Printers.
Section 16 defines a generic schema for Printer object entries in the
directory service and describes how the entry acts as a bridge to the
actual IPP Printer object. The entry in the directory that
represents the IPP Printer object includes the possibly many URIs for
that Printer object as values in one its attributes.
When a client submits a create request to the Printer object, the When a client submits a create request to the Printer object, the
Printer object validates the request and creates a new Job object. The Printer object validates the request and creates a new Job object.
Printer object assigns the new Job object a URI which is stored in the The Printer object assigns the new Job object a URI which is stored
"job-uri" Job attribute. This URI is then used by clients as the target in the "job-uri" Job attribute. This URI is then used by clients as
for subsequent Job operations. The Printer object generates a Job URI the target for subsequent Job operations. The Printer object
based on its configured security policy and the URI used by the client generates a Job URI based on its configured security policy and the
in the create request. URI used by the client in the create request.
For example, consider a Printer object that supports both a For example, consider a Printer object that supports both a
communication channel secured by the use of SSL3 (using HTTP over SSL3 communication channel secured by the use of SSL3 (using HTTP over
with an "https" schemed URI) and another open communication channel that SSL3 with an "https" schemed URI) and another open communication
is not secured with SSL3 (using a simple "http" schemed URI). If a channel that is not secured with SSL3 (using a simple "http" schemed
client were to submit a job using the secure URI, the Printer object URI). If a client were to submit a job using the secure URI, the
would assign the new Job object a secure URI as well. If a client were Printer object would assign the new Job object a secure URI as well.
to submit a job using the open-channel URI, the Printer would assign the If a client were to submit a job using the open-channel URI, the
new Job object an open-channel URI. Printer would assign the new Job object an open-channel URI.
In addition, the Printer object also populates the Job object's "job- In addition, the Printer object also populates the Job object's
printer-uri" attribute. This is a reference back to the Printer object "job-printer-uri" attribute. This is a reference back to the Printer
that created the Job object. If a client only has access to a Job object that created the Job object. If a client only has access to a
object's "job-uri" identifier, the client can query the Job's "job- Job object's "job-uri" identifier, the client can query the Job's
printer-uri" attribute in order to determine which Printer object "job-printer-uri" attribute in order to determine which Printer
created the Job object. If the Printer object supports more than one object created the Job object. If the Printer object supports more
URI, the Printer object picks the one URI supplied by the client when than one URI, the Printer object picks the one URI supplied by the
creating the job to build the value for and to populate the Job's "job- client when creating the job to build the value for and to populate
printer-uri" attribute. the Job's "job-printer-uri" attribute.
Allowing Job objects to have URIs allows for flexibility and Allowing Job objects to have URIs allows for flexibility and
scalability. For example, in some implementations, the Printer object scalability. For example, in some implementations, the Printer
might create Jobs that are processed in the same local environment as object might create Jobs that are processed in the same local
the Printer object itself. In this case, the Job URI might just be a environment as the Printer object itself. In this case, the Job URI
composition of the Printer's URI and some unique component for the Job might just be a composition of the Printer's URI and some unique
object, such as the unique 32-bit positive integer mentioned later in component for the Job object, such as the unique 32-bit positive
this paragraph. In other implementations, the Printer object might be a integer mentioned later in this paragraph. In other implementations,
central clearing-house for validating all Job object creation requests, the Printer object might be a central clearing-house for validating
but the Job object itself might be created in some environment that is all Job object creation requests, but the Job object itself might be
remote from the Printer object. In this case, the Job object's URI may created in some environment that is remote from the Printer object.
have no physical-location relationship at all to the Printer object's In this case, the Job object's URI may have no physical-location
URI. Again, the fact that Job objects have URIs allows for flexibility relationship at all to the Printer object's URI. Again, the fact
and scalability, however, many existing printing systems have local that Job objects have URIs allows for flexibility and scalability,
models or interface constraints that force print jobs to be identified however, many existing printing systems have local models or
using only a 32-bit positive integer rather than an independent URI. interface constraints that force print jobs to be identified using
This numeric Job ID is only unique within the context of the Printer only a 32-bit positive integer rather than an independent URI. This
object to which the create request was originally submitted. Therefore, numeric Job ID is only unique within the context of the Printer
in order to allow both types of client access to IPP Job objects (either object to which the create request was originally submitted.
by Job URI or by numeric Job ID), when the Printer object successfully Therefore, in order to allow both types of client access to IPP Job
processes a create request and creates a new Job object, the Printer objects (either by Job URI or by numeric Job ID), when the Printer
object MUST generate both a Job URI and a Job ID. The Job ID (stored in object successfully processes a create request and creates a new Job
the "job-id" attribute) only has meaning in the context of the Printer object, the Printer object MUST generate both a Job URI and a Job ID.
object to which the create request was originally submitted. This The Job ID (stored in the "job-id" attribute) only has meaning in the
requirement to support both Job URIs and Job IDs allows all types of context of the Printer object to which the create request was
originally submitted. This requirement to support both Job URIs and
Job IDs allows all types of clients to access Printer objects and Job
objects no matter the local constraints imposed on the client
implementation.
Isaacson, Powell Expires May 16, 1999 In addition to identifiers, Printer objects and Job objects have
clients to access Printer objects and Job objects no matter the local names ("printer-name" and "job-name"). An object name NEED NOT be
constraints imposed on the client implementation. unique across all instances of all objects. A Printer object's name
is chosen and set by an administrator through some mechanism outside
the scope of IPP/1.0. A Job object's name is optionally chosen and
supplied by the IPP client submitting the job. If the client does
not supply a Job object name, the Printer object generates a name for
the new Job object. In all cases, the name only has local meaning.
In addition to identifiers, Printer objects and Job objects have names To summarize:
("printer-name" and "job-name"). An object name NEED NOT be unique
across all instances of all objects. A Printer object's name is chosen
and set by an administrator through some mechanism outside the scope of
IPP/1.0. A Job object's name is optionally chosen and supplied by the
IPP client submitting the job. If the client does not supply a Job
object name, the Printer object generates a name for the new Job object.
In all cases, the name only has local meaning.
To summarize: - Each Printer object is identified with one or more URIs. The
Printer's "printer-uri-supported" attribute contains the URI(s).
- Each Printer object is identified with one or more URIs. The - The Printer object's "uri-security-supported" attribute
Printer's "printer-uri-supported" attribute contains the URI(s). identifies the communication channel security protocols that may
- The Printer object's "uri-security-supported" attribute identifies or may not have been configured for the various Printer object
the communication channel security protocols that may or may not URIs (e.g., 'ssl3' or 'none').
have been configured for the various Printer object URIs (e.g., - Each Job object is identified with a Job URI. The Job's "job-uri"
'ssl3' or 'none'). attribute contains the URI.
- Each Job object is identified with a Job URI. The Job's "job-uri" - Each Job object is also identified with Job ID which is a 32-bit,
attribute contains the URI. positive integer. The Job's "job-id" attribute contains the Job
- Each Job object is also identified with Job ID which is a 32-bit, ID. The Job ID is only unique within the context of the Printer
positive integer. The Job's "job-id" attribute contains the Job object which created the Job object.
ID. The Job ID is only unique within the context of the Printer - Each Job object has a "job-printer-uri" attribute which contains
object which created the Job object. the URI of the Printer object that was used to create the Job
- Each Job object has a "job-printer-uri" attribute which contains object. This attribute is used to determine the Printer object
the URI of the Printer object that was used to create the Job that created a Job object when given only the URI for the Job
object. This attribute is used to determine the Printer object object. This linkage is necessary to determine the languages,
that created a Job object when given only the URI for the Job charsets, and operations which are supported on that Job (the
object. This linkage is necessary to determine the languages, basis for such support comes from the creating Printer object).
charsets, and operations which are supported on that Job (the basis - Each Printer object has a name (which is not necessarily unique).
for such support comes from the creating Printer object). The administrator chooses and sets this name through some
- Each Printer object has a name (which is not necessarily unique). mechanism outside the scope of IPP/1.0 itself. The Printer
The administrator chooses and sets this name through some mechanism object's "printer-name" attribute contains the name.
outside the scope of IPP/1.0 itself. The Printer object's - Each Job object has a name (which is not necessarily unique). The
"printer-name" attribute contains the name. client optionally supplies this name in the create request. If
- Each Job object has a name (which is not necessarily unique). The the client does not supply this name, the Printer object generates
client optionally supplies this name in the create request. If the a name for the Job object. The Job object's "job-name" attribute
client does not supply this name, the Printer object generates a contains the name.
name for the Job object. The Job object's "job-name" attribute
contains the name.
3. IPP Operations 3. IPP Operations
IPP objects support operations. An operation consists of a request and IPP objects support operations. An operation consists of a request
a response. When a client communicates with an IPP object, the client and a response. When a client communicates with an IPP object, the
issues an operation request to the URI for that object. Operation client issues an operation request to the URI for that object.
requests and responses have parameters that identify the operation. Operation requests and responses have parameters that identify the
Operations also have attributes that affect the run-time characteristics operation. Operations also have attributes that affect the run-time
of the operation (the intended target, localization information, etc.). characteristics of the operation (the intended target, localization
These operation-specific attributes are called operation attributes (as information, etc.). These operation-specific attributes are called
compared to object attributes such as Printer object attributes or Job operation attributes (as compared to object attributes such as
Printer object attributes or Job object attributes). Each request
Isaacson, Powell Expires May 16, 1999 carries along with it any operation attributes, object attributes,
object attributes). Each request carries along with it any operation and/or document data required to perform the operation. Each request
attributes, object attributes, and/or document data required to perform requires a response from the object. Each response indicates success
the operation. Each request requires a response from the object. Each or failure of the operation with a status code as a response
response indicates success or failure of the operation with a status parameter. The response contains any operation attributes, object
code as a response parameter. The response contains any operation attributes, and/or status messages generated during the execution of
attributes, object attributes, and/or status messages generated during the operation request.
the execution of the operation request.
This section describes the semantics of the IPP operations, both This section describes the semantics of the IPP operations, both
requests and responses, in terms of the parameters, attributes, and requests and responses, in terms of the parameters, attributes, and
other data associated with each operation. other data associated with each operation.
The IPP/1.0 Printer operations are: The IPP/1.0 Printer operations are:
Print-Job (section 3.2.1) Print-Job (section 3.2.1)
Print-URI (section 3.2.2) Print-URI (section 3.2.2)
Validate-Job (section 3.2.3) Validate-Job (section 3.2.3)
Create-Job (section 3.2.4) Create-Job (section 3.2.4)
Get-Printer-Attributes (section 3.2.5) Get-Printer-Attributes (section 3.2.5)
Get-Jobs (section 3.2.6) Get-Jobs (section 3.2.6)
The Job operations are: The Job operations are:
Send-Document (section 3.3.1) Send-Document (section 3.3.1)
Send-URI (section 3.3.2) Send-URI (section 3.3.2)
Cancel-Job (section 3.3.3) Cancel-Job (section 3.3.3)
Get-Job-Attributes (section 3.3.4) Get-Job-Attributes (section 3.3.4)
The Send-Document and Send-URI Job operations are used to add a new The Send-Document and Send-URI Job operations are used to add a new
document to an existing multi-document Job object created using the document to an existing multi-document Job object created using the
Create-Job operation. Create-Job operation.
3.1 Common Semantics 3.1 Common Semantics
All IPP operations require some common parameters and operation All IPP operations require some common parameters and operation
attributes. These common elements and their semantic characteristics attributes. These common elements and their semantic characteristics
are defined and described in more detail in the following sections. are defined and described in more detail in the following sections.
3.1.1 Required Parameters 3.1.1 Required Parameters
Every operation request contains the following REQUIRED parameters: Every operation request contains the following REQUIRED parameters:
- a "version-number", - a "version-number",
- an "operation-id", - an "operation-id",
- a "request-id", and - a "request-id", and
- the attributes that are REQUIRED for that type of request. - the attributes that are REQUIRED for that type of request.
Every operation response contains the following REQUIRED parameters: Every operation response contains the following REQUIRED parameters:
Isaacson, Powell Expires May 16, 1999 - a "version-number",
- a "version-number", - a "status-code",
- a "status-code", - the "request-id" that was supplied in the corresponding request,
- the "request-id" that was supplied in the corresponding request, and
and - the attributes that are REQUIRED for that type of response.
- the attributes that are REQUIRED for that type of response.
The encoding and transport document [IPP-PRO] defines special rules for The encoding and transport document [RFC2565] defines special rules
the encoding of these parameters. All other operation elements are for the encoding of these parameters. All other operation elements
represented using the more generic encoding rules for attributes and are represented using the more generic encoding rules for attributes
groups of attributes. and groups of attributes.
3.1.2 Operation IDs and Request IDs 3.1.2 Operation IDs and Request IDs
Each IPP operation request includes an identifying "operation-id" value. Each IPP operation request includes an identifying "operation-id"
Valid values are defined in the "operations-supported" Printer attribute value. Valid values are defined in the "operations-supported"
section (see section 4.4.13). The client specifies which operation is Printer attribute section (see section 4.4.13). The client specifies
being requested by supplying the correct "operation-id" value. which operation is being requested by supplying the correct
"operation-id" value.
In addition, every invocation of an operation is identified by a In addition, every invocation of an operation is identified by a
"request-id" value. For each request, the client chooses the "request- "request-id" value. For each request, the client chooses the
id" which MUST be an integer (possibly unique depending on client "request-id" which MUST be an integer (possibly unique depending on
requirements) in the range from 1 to 2**31 - 1 (inclusive). This client requirements) in the range from 1 to 2**31 - 1 (inclusive).
"request-id" allows clients to manage multiple outstanding requests. The This "request-id" allows clients to manage multiple outstanding
receiving IPP object copies all 32-bits of the client-supplied "request- requests. The receiving IPP object copies all 32-bits of the client-
id" attribute into the response so that the client can match the supplied "request-id" attribute into the response so that the client
response with the correct outstanding request, even if the "request-id" can match the response with the correct outstanding request, even if
is out of range. If the request is terminated before the complete the "request-id" is out of range. If the request is terminated
"request-id" is received, the IPP object rejects the request and returns before the complete "request-id" is received, the IPP object rejects
a response with a "request-id" of 0. the request and returns a response with a "request-id" of 0.
Note: In some cases, the transport protocol underneath IPP might be a Note: In some cases, the transport protocol underneath IPP might be a
connection oriented protocol that would make it impossible for a client connection oriented protocol that would make it impossible for a
to receive responses in any order other than the order in which the client to receive responses in any order other than the order in
corresponding requests were sent. In such cases, the "request-id" which the corresponding requests were sent. In such cases, the
attribute would not be essential for correct protocol operation. "request-id" attribute would not be essential for correct protocol
However, in other mappings, the operation responses can come back in any operation. However, in other mappings, the operation responses can
order. In these cases, the "request-id" would be essential. come back in any order. In these cases, the "request-id" would be
essential.
3.1.3 Attributes 3.1.3 Attributes
Operation requests and responses are both composed of groups of Operation requests and responses are both composed of groups of
attributes and/or document data. The attributes groups are: attributes and/or document data. The attributes groups are:
- Operation Attributes: These attributes are passed in the operation
and affect the IPP object's behavior while processing the operation
request and may affect other attributes or groups of attributes.
Some operation attributes describe the document data associated
with the print job and are associated with new Job objects, however
most operation attributes do not persist beyond the life of the
operation. The description of each operation attribute includes
conformance statements indicating which operation attributes are
REQUIRED and which are OPTIONAL for an IPP object to support and
which attributes a client MUST supply in a request and an IPP
object MUST supply in a response.
Isaacson, Powell Expires May 16, 1999
- Job Template Attributes: These attributes affect the processing of - Operation Attributes: These attributes are passed in the
a job. A client OPTIONALLY supplies Job Template Attributes in a operation and affect the IPP object's behavior while processing
create request, and the receiving object MUST be prepared to the operation request and may affect other attributes or groups
receive all supported attributes. The Job object can later be of attributes. Some operation attributes describe the document
queried to find out what Job Template attributes were originally data associated with the print job and are associated with new
requested in the create request, and such attributes are returned Job objects, however most operation attributes do not persist
in the response as Job Object Attributes. The Printer object can beyond the life of the operation. The description of each
be queried about its Job Template attributes to find out what type operation attribute includes conformance statements indicating
of job processing capabilities are supported and/or what the which operation attributes are REQUIRED and which are OPTIONAL
default job processing behaviors are, though such attributes are for an IPP object to support and which attributes a client MUST
returned in the response as Printer Object Attributes. The "ipp- supply in a request and an IPP object MUST supply in a response.
attribute-fidelity" operation attribute affects processing of all - Job Template Attributes: These attributes affect the processing
client-supplied Job Template attributes (see section 16 for a full of a job. A client OPTIONALLY supplies Job Template Attributes
description of "ipp-attribute-fidelity" and its relationship to in a create request, and the receiving object MUST be prepared to
other attributes). receive all supported attributes. The Job object can later be
- Job Object Attributes: These attributes are returned in response to queried to find out what Job Template attributes were originally
a query operation directed at a Job object. requested in the create request, and such attributes are returned
- Printer Object Attributes: These attributes are returned in in the response as Job Object Attributes. The Printer object can
response to a query operation directed at a Printer object. be queried about its Job Template attributes to find out what
- Unsupported Attributes: In a create request, the client supplies a type of job processing capabilities are supported and/or what the
set of Operation and Job Template attributes. If any of these default job processing behaviors are, though such attributes are
attributes or their values is unsupported by the Printer object, returned in the response as Printer Object Attributes. The
the Printer object returns the set of unsupported attributes in the "ipp-attribute-fidelity" operation attribute affects processing
response. Section 16 gives a full description of how Job Template of all client-supplied Job Template attributes (see section 15
attributes supplied by the client in a create request are processed for a full description of "ipp-attribute-fidelity" and its
by the Printer object and how unsupported attributes are returned relationship to other attributes).
to the client. Because of extensibility, any IPP object might - Job Object Attributes: These attributes are returned in response
receive a request that contains new or unknown attributes or values to a query operation directed at a Job object.
for which it has no support. In such cases, the IPP object - Printer Object Attributes: These attributes are returned in
processes what it can and returns the unsupported attributes in the response to a query operation directed at a Printer object.
response. - Unsupported Attributes: In a create request, the client supplies
a set of Operation and Job Template attributes. If any of these
attributes or their values is unsupported by the Printer object,
the Printer object returns the set of unsupported attributes in
the response. Section 15 gives a full description of how Job
Template attributes supplied by the client in a create request
are processed by the Printer object and how unsupported
attributes are returned to the client. Because of extensibility,
any IPP object might receive a request that contains new or
unknown attributes or values for which it has no support. In such
cases, the IPP object processes what it can and returns the
unsupported attributes in the response.
Later in this section, each operation is formally defined by identifying Later in this section, each operation is formally defined by
the allowed and expected groups of attributes for each request and identifying the allowed and expected groups of attributes for each
response. The model identifies a specific order for each group in each request and response. The model identifies a specific order for each
request or response, but the attributes within each group may be in any group in each request or response, but the attributes within each
order, unless specified otherwise. group may be in any order, unless specified otherwise.
Each attribute specification includes the attribute's name followed by Each attribute specification includes the attribute's name followed
the name of its attribute syntax(es) in parenthesizes. In addition, by the name of its attribute syntax(es) in parenthesizes. In
each 'integer' attribute is followed by the allowed range in addition, each 'integer' attribute is followed by the allowed range
parentheses, (m:n), for values of that attribute. Each 'text' or 'name' in parentheses, (m:n), for values of that attribute. Each 'text' or
attribute is followed by the maximum size in octets in parentheses, 'name' attribute is followed by the maximum size in octets in
(size), for values of that attribute. For more details on attribute parentheses, (size), for values of that attribute. For more details
syntax notation, see the descriptions of these attributes syntaxes in on attribute syntax notation, see the descriptions of these
section 4.1. attributes syntaxes in section 4.1.
Note: Document data included in the operation is not strictly an Note: Document data included in the operation is not strictly an
attribute, but it is treated as a special attribute group for ordering attribute, but it is treated as a special attribute group for
purposes. The only operations that support supplying the document data ordering purposes. The only operations that support supplying the
within an operation request are Print-Job and Send-Document. There are document data within an operation request are Print-Job and Send-
no operation responses that include document data. Document. There are no operation responses that include document
data.
Isaacson, Powell Expires May 16, 1999 Note: Some operations are REQUIRED for IPP objects to support; the
Note: Some operations are REQUIRED for IPP objects to support; the others are OPTIONAL (see section 5.2.2). Therefore, before using an
others are OPTIONAL (see section 5.2.2). Therefore, before using an OPTIONAL operation, a client SHOULD first use the REQUIRED Get-
OPTIONAL operation, a client SHOULD first use the REQUIRED Get-Printer- Printer-Attributes operation to query the Printer's "operations-
Attributes operation to query the Printer's "operations-supported" supported" attribute in order to determine which OPTIONAL Printer and
attribute in order to determine which OPTIONAL Printer and Job Job operations are actually supported. The client SHOULD NOT use an
operations are actually supported. The client SHOULD NOT use an OPTIONAL operation that is not supported. When an IPP object
OPTIONAL operation that is not supported. When an IPP object receives a receives a request to perform an operation it does not support, it
request to perform an operation it does not support, it returns the returns the 'server-error-operation-not-supported' status code (see
'server-error-operation-not-supported' status code (see section section 13.1.5.2). An IPP object is non-conformant if it does not
14.1.5.2). An IPP object is non-conformant if it does not support a support a REQUIRED operation.
REQUIRED operation.
3.1.4 Character Set and Natural Language Operation Attributes 3.1.4 Character Set and Natural Language Operation Attributes
Some Job and Printer attributes have values that are text strings and Some Job and Printer attributes have values that are text strings and
names intended for human understanding rather than machine understanding names intended for human understanding rather than machine
(see the 'text' and 'name' attribute syntax descriptions in section understanding (see the 'text' and 'name' attribute syntax
4.1). The following sections describe two special Operation Attributes descriptions in section 4.1). The following sections describe two
called "attributes-charset" and "attributes-natural-language". These special Operation Attributes called "attributes-charset" and
attributes are always part of the Operation Attributes group. For most "attributes-natural-language". These attributes are always part of
attribute groups, the order of the attributes within the group is not the Operation Attributes group. For most attribute groups, the order
important. However, for these two attributes within the Operation of the attributes within the group is not important. However, for
Attributes group, the order is critical. The "attributes-charset" these two attributes within the Operation Attributes group, the order
attribute MUST be the first attribute in the group and the "attributes- is critical. The "attributes-charset" attribute MUST be the first
natural-language" attribute MUST be the second attribute in the group. attribute in the group and the "attributes-natural-language"
In other words, these attributes MUST be supplied in every IPP request attribute MUST be the second attribute in the group. In other words,
and response, they MUST come first in the group, and MUST come in the these attributes MUST be supplied in every IPP request and response,
specified order. For job creation operations, the IPP Printer they MUST come first in the group, and MUST come in the specified
implementation saves these two attributes with the new Job object as Job order. For job creation operations, the IPP Printer implementation
Description attributes. For the sake of brevity in this document, these saves these two attributes with the new Job object as Job Description
operation attribute descriptions are not repeated with every operation attributes. For the sake of brevity in this document, these
request and response, but have a reference back to this section instead. operation attribute descriptions are not repeated with every
operation request and response, but have a reference back to this
section instead.
3.1.4.1 Request Operation Attributes 3.1.4.1 Request Operation Attributes
The client MUST supply and the Printer object MUST support the following The client MUST supply and the Printer object MUST support the
REQUIRED operation attributes in every IPP/1.0 operation request: following REQUIRED operation attributes in every IPP/1.0 operation
request:
"attributes-charset" (charset):
This operation attribute identifies the charset (coded character
set and encoding method) used by any 'text' and 'name' attributes
that the client is supplying in this request. It also identifies
the charset that the Printer object MUST use (if supported) for all
'text' and 'name' attributes and status messages that the Printer
object returns in the response to this request. See Sections 4.1.1
and 4.1.2 for the specification of the 'text' and 'name' attribute
syntaxes.
All clients and IPP objects MUST support the 'utf-8' charset
[RFC2044] and MAY support additional charsets provided that they
are registered with IANA [IANA-CS]. If the Printer object does not
support the client supplied charset value, the Printer object MUST
reject the request, set the "attributes-charset" to 'utf-8' in the
Isaacson, Powell Expires May 16, 1999
response, and return the 'client-error-charset-not-supported'
status code and any 'text' or 'name' attributes using the 'utf-8'
charset. The Printer object MUST indicate the charset(s) supported
as the values of the "charset-supported" Printer attribute (see
Section 4.4.15), so that the client can query to determine which
charset(s) are supported.
Note to client implementers: Since IPP objects are only required to "attributes-charset" (charset):
support the 'utf-8' charset, in order to maximize interoperability This operation attribute identifies the charset (coded character
with multiple IPP object implementations, a client may want to set and encoding method) used by any 'text' and 'name'
supply 'utf-8' in the "attributes-charset" operation attribute, attributes that the client is supplying in this request. It
even though the client is only passing and able to present a also identifies the charset that the Printer object MUST use (if
simpler charset, such as US-ASCII or ISO-8859-1. Then the client supported) for all 'text' and 'name' attributes and status
will have to filter out (or charset convert) those characters that messages that the Printer object returns in the response to this
are returned in the response that it cannot present to its user. request. See Sections 4.1.1 and 4.1.2 for the specification of
On the other hand, if both the client and the IPP objects also the 'text' and 'name' attribute syntaxes.
support a charset in common besides utf-8, the client may want to
use that charset in order to avoid charset conversion or data loss.
See the 'charset' attribute syntax description in Section 4.1.7 for All clients and IPP objects MUST support the 'utf-8' charset
the syntax and semantic interpretation of the values of this [RFC2279] and MAY support additional charsets provided that they
attribute and for example values. are registered with IANA [IANA-CS]. If the Printer object does
not support the client supplied charset value, the Printer
object MUST reject the request, set the "attributes-charset" to
'utf-8' in the response, and return the 'client-error-charset-
not-supported' status code and any 'text' or 'name' attributes
using the 'utf-8' charset. The Printer object MUST indicate the
charset(s) supported as the values of the "charset-supported"
Printer attribute (see Section 4.4.15), so that the client can
query to determine which charset(s) are supported.
"attributes-natural-language" (naturalLanguage): Note to client implementers: Since IPP objects are only required
This operation attribute identifies the natural language used by to support the 'utf-8' charset, in order to maximize
any 'text' and 'name' attributes that the client is supplying in interoperability with multiple IPP object implementations, a
this request. This attribute also identifies the natural language client may want to supply 'utf-8' in the "attributes-charset"
that the Printer object SHOULD use for all 'text' and 'name' operation attribute, even though the client is only passing and
attributes and status messages that the Printer object returns in able to present a simpler charset, such as US-ASCII or ISO-
the response to this request. 8859-1. Then the client will have to filter out (or charset
convert) those characters that are returned in the response that
it cannot present to its user. On the other hand, if both the
client and the IPP objects also support a charset in common
besides utf-8, the client may want to use that charset in order
to avoid charset conversion or data loss.
There are no REQUIRED natural languages required for the Printer See the 'charset' attribute syntax description in Section 4.1.7
object to support. However, the Printer object's "generated- for the syntax and semantic interpretation of the values of this
natural-language-supported" attribute identifies the natural attribute and for example values.
languages supported by the Printer object and any contained Job
objects for all text strings generated by the IPP object. A client
MAY query this attribute to determine which natural language(s) are
supported for generated messages.
For any of the attributes for which the Printer object generates "attributes-natural-language" (naturalLanguage):
text, i.e., for the "job-state-message", "printer-state-message", This operation attribute identifies the natural language used by
and status messages (see Section 3.1.6), the Printer object MUST be any 'text' and 'name' attributes that the client is supplying in
able to generate these text strings in any of its supported natural this request. This attribute also identifies the natural
languages. If the client requests a natural language that is not language that the Printer object SHOULD use for all 'text' and '
supported, the Printer object MUST return these generated messages name' attributes and status messages that the Printer object
in the Printer's configured natural language as specified by the returns in the response to this request.
Printer's "natural-language-configured" attribute" (see Section
4.4.16).
For other 'text' and 'name' attributes supplied by the client, There are no REQUIRED natural languages required for the Printer
authentication system, operator, system administrator, or object to support. However, the Printer object's "generated-
manufacturer (i.e., for "job-originating-user-name", "printer-name" natural-language-supported" attribute identifies the natural
(name), "printer-location" (text), "printer-info" (text), and languages supported by the Printer object and any contained Job
"printer-make-and-model" (text)), the Printer object is only objects for all text strings generated by the IPP object. A
client MAY query this attribute to determine which natural
language(s) are supported for generated messages.
Isaacson, Powell Expires May 16, 1999 For any of the attributes for which the Printer object generates
required to support the configured natural language of the Printer text, i.e., for the "job-state-message", "printer-state-
identified by the Printer object's "natural-language-configured" message", and status messages (see Section 3.1.6), the Printer
attribute, though support of additional natural languages for these object MUST be able to generate these text strings in any of its
attributes is permitted. supported natural languages. If the client requests a natural
language that is not supported, the Printer object MUST return
these generated messages in the Printer's configured natural
language as specified by the Printer's "natural-language-
configured" attribute" (see Section 4.4.16).
For any 'text' or 'name' attribute in the request that is in a For other 'text' and 'name' attributes supplied by the client,
different natural language than the value supplied in the authentication system, operator, system administrator, or
"attributes-natural-language" operation attribute, the client MUST manufacturer (i.e., for "job-originating-user-name", "printer-
use the Natural Language Override mechanism (see sections 4.1.1.2 name" (name), "printer-location" (text), "printer-info" (text),
and 4.1.2.2) for each such attribute value supplied. The client and "printer-make-and-model" (text)), the Printer object is only
MAY use the Natural Language Override mechanism redundantly, i.e., required to support the configured natural language of the
use it even when the value is in the same natural language as the Printer identified by the Printer object's "natural-language-
value supplied in the "attributes-natural-language" operation configured" attribute, though support of additional natural
attribute of the request. languages for these attributes is permitted.
The IPP object MUST accept any natural language and any Natural For any 'text' or 'name' attribute in the request that is in a
Language Override, whether the IPP object supports that natural different natural language than the value supplied in the
language or not (and independent of the value of the "ipp- "attributes-natural-language" operation attribute, the client
attribute-fidelity" Operation attribute). That is the IPP object MUST use the Natural Language Override mechanism (see sections
accepts all client supplied values no matter what the values are in 4.1.1.2 and 4.1.2.2) for each such attribute value supplied.
the Printer object's "generated-natural-language-supported" The client MAY use the Natural Language Override mechanism
attribute. That attribute, "generated-natural-language-supported", redundantly, i.e., use it even when the value is in the same
only applies to generated messages, not client supplied messages. natural language as the value supplied in the "attributes-
The IPP object MUST remember that natural language for all client- natural-language" operation attribute of the request.
supplied attributes, and when returning those attributes in
response to a query, the IPP object MUST indicate that natural
language.
Each value whose attribute syntax type is .text. or .name. (see The IPP object MUST accept any natural language and any Natural
sections 4.1.1 and 4.1.2) has an Associated Natural-Language. This Language Override, whether the IPP object supports that natural
document does not specify how this association is stored in a language or not (and independent of the value of the "ipp-
Printer or Job object. When such a value is encoded in a request attribute-fidelity" Operation attribute). That is the IPP
or response, the natural language is either implicit or explicit: object accepts all client supplied values no matter what the
values are in the Printer object's "generated-natural-language-
supported" attribute. That attribute, "generated-natural-
language-supported", only applies to generated messages,
not client supplied messages. The IPP object MUST remember that
natural language for all client-supplied attributes, and when
returning those attributes in response to a query, the IPP
object MUST indicate that natural language.
@ In the implicit case, the value contains only the text/name Each value whose attribute syntax type is 'text' or 'name' (see
value, and the language is specified by the .attributes- sections 4.1.1 and 4.1.2) has an Associated Natural-Language.
natural-language. operation attribute in the request or This document does not specify how this association is stored in
response (see sections 4.1.1.1 textWithoutLanguage and a Printer or Job object. When such a value is encoded in a
4.1.2.1 nameWithoutLanguage). request or response, the natural language is either implicit or
explicit:
@ In the explicit case (also known as the Natural-Language - In the implicit case, the value contains only the
Override case), the value contains both the language and text/name value, and the language is specified by the
the text/name value (see sections 4.1.1.2 textWithLanguage "attributes-natural-language" operation attribute in the
and 4.1.2.2 nameWithLanguage). request or response (see sections 4.1.1.1
textWithoutLanguage and 4.1.2.1 nameWithoutLanguage).
For example, the "job-name" attribute MAY be supplied by the client - In the explicit case (also known as the Natural-Language
in a create request. The text value for this attribute will be in Override case), the value contains both the language and
the natural language identified by the "attribute-natural-language" the text/name value (see sections 4.1.1.2
attribute, or if different, as identified by the Natural Language textWithLanguage and 4.1.2.2 nameWithLanguage).
Override mechanism. If supplied, the IPP object will use the value
of the "job-name" attribute to populate the Job object's "job-name"
attribute. Whenever any client queries the Job object's "job-name"
attribute, the IPP object returns the attribute as stored and uses
the Natural Language Override mechanism to specify the natural
Isaacson, Powell Expires May 16, 1999 For example, the "job-name" attribute MAY be supplied by the
language, if it is different from that reported in the "attributes- client in a create request. The text value for this attribute
natural-language" operation attribute of the response. The IPP will be in the natural language identified by the "attribute-
object MAY use the Natural Language Override mechanism redundantly, natural-language" attribute, or if different, as identified by
i.e., use it even when the value is in the same natural language the Natural Language Override mechanism. If supplied, the IPP
as the value supplied in the "attributes-natural-language" object will use the value of the "job-name" attribute to
operation attribute of the response. populate the Job object's "job-name" attribute. Whenever any
client queries the Job object's "job-name" attribute, the IPP
object returns the attribute as stored and uses the Natural
Language Override mechanism to specify the natural language, if
it is different from that reported in the "attributes-natural-
language" operation attribute of the response. The IPP object
MAY use the Natural Language Override mechanism redundantly,
i.e., use it even when the value is in the same natural language
as the value supplied in the "attributes-natural-language"
operation attribute of the response.
An IPP object MUST NOT reject a request based on a supplied natural An IPP object MUST NOT reject a request based on a supplied
language in an "attributes-natural-language" Operation attribute or natural language in an "attributes-natural-language" Operation
in any attribute that uses the Natural Language Override. attribute or in any attribute that uses the Natural Language
Override.
See the 'naturalLanguage' attribute syntax description in section See the 'naturalLanguage' attribute syntax description in
4.1.8 for the syntax and semantic interpretation of the values of section 4.1.8 for the syntax and semantic interpretation of the
this attribute and for example values. values of this attribute and for example values.
Clients SHOULD NOT supply 'text' or 'name' attributes that use an Clients SHOULD NOT supply 'text' or 'name' attributes that use an
illegal combination of natural language and charset. For example, illegal combination of natural language and charset. For example,
suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and
'iso-8859-7'. Suppose also, that it supports natural languages 'en' 'iso-8859-7'. Suppose also, that it supports natural languages 'en'
(English), 'fr' (French), and 'el' (Greek). Although the Printer object (English), 'fr' (French), and 'el' (Greek). Although the Printer
supports the charset 'iso-8859-1' and natural language 'el', it probably object supports the charset 'iso-8859-1' and natural language 'el',
does not support the combination of Greek text strings using the 'iso- it probably does not support the combination of Greek text strings
8859-1' charset. The Printer object handles this apparent using the 'iso-8859-1' charset. The Printer object handles this
incompatibility differently depending on the context in which it occurs: apparent incompatibility differently depending on the context in
which it occurs:
- In a create request: If the client supplies a text or name - In a create request: If the client supplies a text or name
attribute (for example, the "job-name" operation attribute) that attribute (for example, the "job-name" operation attribute) that
uses an apparently incompatible combination, it is a client choice uses an apparently incompatible combination, it is a client
that does not affect the Printer object or its correct operation. choice that does not affect the Printer object or its correct
Therefore, the Printer object simply accepts the client supplied operation. Therefore, the Printer object simply accepts the
value, stores it with the Job object, and responds back with the client supplied value, stores it with the Job object, and
same combination whenever the client (or any client) queries for responds back with the same combination whenever the client (or
that attribute. any client) queries for that attribute.
-In a query-type operation, like Get-Printer-Attributes: If the - In a query-type operation, like Get-Printer-Attributes: If the
client requests an apparently incompatible combination, the Printer client requests an apparently incompatible combination, the
object responds (as described in section 3.1.4.2) using the Printer object responds (as described in section 3.1.4.2) using
Printer's configured natural language rather than the natural the Printer's configured natural language rather than the natural
language requested by the client. language requested by the client.
In either case, the Printer object does not reject the request because In either case, the Printer object does not reject the request
of the apparent incompatibility. The potential incompatible combination because of the apparent incompatibility. The potential incompatible
of charset and natural language can occur either at the global operation combination of charset and natural language can occur either at the
level or at the Natural Language Override attribute-by-attribute level. global operation level or at the Natural Language Override
In addition, since the response always includes explicit charset and attribute-by-attribute level. In addition, since the response always
natural language information, there is never any question or ambiguity includes explicit charset and natural language information, there is
in how the client interprets the response. never any question or ambiguity in how the client interprets the
response.
3.1.4.2 Response Operation Attributes 3.1.4.2 Response Operation Attributes
The Printer object MUST supply and the client MUST support the following The Printer object MUST supply and the client MUST support the
REQUIRED operation attributes in every IPP/1.0 operation response: following REQUIRED operation attributes in every IPP/1.0 operation
response:
Isaacson, Powell Expires May 16, 1999 "attributes-charset" (charset):
"attributes-charset" (charset): This operation attribute identifies the charset used by any '
This operation attribute identifies the charset used by any 'text' text' and 'name' attributes that the Printer object is returning
and 'name' attributes that the Printer object is returning in this in this response. The value in this response MUST be the same
response. The value in this response MUST be the same value as the value as the "attributes-charset" operation attribute supplied
"attributes-charset" operation attribute supplied by the client in by the client in the request. If this is not possible
the request. If this is not possible (i.e., the charset requested (i.e., the charset requested is not supported), the request
is not supported), the request would have been rejected. See would have been rejected. See "attributes-charset" described in
"attributes-charset" described in Section 3.1.4.1 above. Section 3.1.4.1 above.
If the Printer object supports more than just the 'utf-8' charset, If the Printer object supports more than just the 'utf-8'
the Printer object MUST be able to code convert between each of the charset, the Printer object MUST be able to code convert between
charsets supported on a highest fidelity possible basis in order to each of the charsets supported on a highest fidelity possible
return the 'text' and 'name' attributes in the charset requested by basis in order to return the 'text' and 'name' attributes in the
the client. However, some information loss MAY occur during the charset requested by the client. However, some information loss
charset conversion depending on the charsets involved. For MAY occur during the charset conversion depending on the
example, the Printer object may convert from a UTF-8 'a' to a US- charsets involved. For example, the Printer object may convert
ASCII 'a' (with no loss of information), from an ISO Latin 1 from a UTF-8 'a' to a US-ASCII 'a' (with no loss of
CAPITAL LETTER A WITH ACUTE ACCENT to US-ASCII 'A' (losing the information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE
accent), or from a UTF-8 Japanese Kanji character to some ISO Latin ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8
1 error character indication such as '?', decimal code equivalent, Japanese Kanji character to some ISO Latin 1 error character
or to the absence of a character, depending on implementation. indication such as '?', decimal code equivalent, or to the
absence of a character, depending on implementation.
Note: Whether an implementation that supports more than one charset Note: Whether an implementation that supports more than one
stores the data in the charset supplied by the client or code charset stores the data in the charset supplied by the client or
converts to one of the other supported charsets, depends on code converts to one of the other supported charsets, depends on
implementation. The strategy should try to minimize loss of implementation. The strategy should try to minimize loss of
information during code conversion. On each response, such an information during code conversion. On each response, such an
implementation converts from its internal charset to that implementation converts from its internal charset to that
requested. requested.
"attributes-natural-language" (naturalLanguage): "attributes-natural-language" (naturalLanguage):
This operation attribute identifies the natural language used by This operation attribute identifies the natural language used by
any 'text' and 'name' attributes that the IPP object is returning any 'text' and 'name' attributes that the IPP object is
in this response. Unlike the "attributes-charset" operation returning in this response. Unlike the "attributes-charset"
attribute, the IPP object NEED NOT return the same value as that operation attribute, the IPP object NEED NOT return the same
supplied by the client in the request. The IPP object MAY return value as that supplied by the client in the request. The IPP
the natural language of the Job object or the Printer's configured object MAY return the natural language of the Job object or the
natural language as identified by the Printer object's "natural- Printer's configured natural language as identified by the
language-configured" attribute, rather than the natural language Printer object's "natural-language-configured" attribute, rather
supplied by the client. For any 'text' or 'name' attribute or than the natural language supplied by the client. For any '
status message in the response that is in a different natural text' or 'name' attribute or status message in the response that
language than the value returned in the "attributes-natural- is in a different natural language than the value returned in
language" operation attribute, the IPP object MUST use the Natural the "attributes-natural-language" operation attribute, the IPP
Language Override mechanism (see sections 4.1.1.2 and 4.1.2.2) on object MUST use the Natural Language Override mechanism (see
each attribute value returned. The IPP object MAY use the Natural sections 4.1.1.2 and 4.1.2.2) on each attribute value returned.
Language Override mechanism redundantly, i.e., use it even when the The IPP object MAY use the Natural Language Override mechanism
value is in the same natural language as the value supplied in the redundantly, i.e., use it even when the value is in the same
"attributes-natural-language" operation attribute of the response. natural language as the value supplied in the "attributes-
natural-language" operation attribute of the response.
3.1.5 Operation Targets 3.1.5 Operation Targets
All IPP operations are directed at IPP objects. For Printer operations, All IPP operations are directed at IPP objects. For Printer
the operation is always directed at a Printer object using one of its operations, the operation is always directed at a Printer object
URIs (i.e., one of the values in the Printer object's "printer-uri- using one of its URIs (i.e., one of the values in the Printer
object's "printer-uri-supported" attribute). Even if the Printer
Isaacson, Powell Expires May 16, 1999 object supports more than one URI, the client supplies only one URI
supported" attribute). Even if the Printer object supports more than as the target of the operation. The client identifies the target
one URI, the client supplies only one URI as the target of the object by supplying the correct URI in the "printer-uri (uri)"
operation. The client identifies the target object by supplying the operation attribute.
correct URI in the "printer-uri (uri)" operation attribute.
For Job operations, the operation is directed at either:
- The Job object itself using the Job object's URI. In this case, For Job operations, the operation is directed at either:
the client identifies the target object by supplying the correct
URI in the "job-uri (uri)" operation attribute.
- The Printer object that created the Job object using both the
Printer objects URI and the Job object's Job ID. Since the Printer
object that created the Job object generated the Job ID, it MUST be
able to correctly associate the client supplied Job ID with the
correct Job object. The client supplies the Printer object's URI
in the "printer-uri (uri)" operation attribute and the Job object's
Job ID in the "job-id (integer(1:MAX))" operation attribute.
If the operation is directed at the Job object directly using the Job - The Job object itself using the Job object's URI. In this case,
object's URI, the client MUST NOT include the redundant "job-id" the client identifies the target object by supplying the correct
operation attribute. URI in the "job-uri (uri)" operation attribute.
- The Printer object that created the Job object using both the
Printer objects URI and the Job object's Job ID. Since the
Printer object that created the Job object generated the Job ID,
it MUST be able to correctly associate the client supplied Job ID
with the correct Job object. The client supplies the Printer
object's URI in the "printer-uri (uri)" operation attribute and
the Job object's Job ID in the "job-id (integer(1:MAX))"
operation attribute.
The operation target attributes are REQUIRED operation attributes that If the operation is directed at the Job object directly using the Job
MUST be included in every operation request. Like the charset and object's URI, the client MUST NOT include the redundant "job-id"
natural language attributes (see section 3.1.4), the operation target operation attribute.
attributes are specially ordered operation attributes. In all cases,
the operation target attributes immediately follow the "attributes-
charset" and "attributes-natural-language" attributes within the
operation attribute group, however the specific ordering rules are:
- In the case where there is only one operation target attribute The operation target attributes are REQUIRED operation attributes
(i.e., either only the "printer-uri" attribute or only the "job- that MUST be included in every operation request. Like the charset
uri" attribute), that attribute MUST be the third attribute in the and natural language attributes (see section 3.1.4), the operation
operation attributes group. target attributes are specially ordered operation attributes. In all
- In the case where Job operations use two operation target cases, the operation target attributes immediately follow the
attributes (i.e., the "printer-uri" and "job-id" attributes), the "attributes-charset" and "attributes-natural-language" attributes
"printer-uri" attribute MUST be the third attribute and the "job- within the operation attribute group, however the specific ordering
id" attribute MUST be the fourth attribute. rules are:
In all cases, the target URIs contained within the body of IPP operation - In the case where there is only one operation target attribute
requests and responses must be in absolute format rather than relative (i.e., either only the "printer-uri" attribute or only the "job-
format (a relative URL identifies a resource with the scope of the HTTP uri" attribute), that attribute MUST be the third attribute in
server, but does not include scheme, host or port). the operation attributes group.
- In the case where Job operations use two operation target
attributes (i.e., the "printer-uri" and "job-id" attributes), the
"printer-uri" attribute MUST be the third attribute and the
"job-id" attribute MUST be the fourth attribute.
The following rules apply to the use of port numbers in URIs that In all cases, the target URIs contained within the body of IPP
identify IPP objects: operation requests and responses must be in absolute format rather
than relative format (a relative URL identifies a resource with the
scope of the HTTP server, but does not include scheme, host or port).
1. If the URI scheme allows the port number to be explicitly included The following rules apply to the use of port numbers in URIs that
in the URI string, and a port number is specified within the URI, identify IPP objects:
then that port number MUST be used by the client to contact the IPP
object.
2. If the URI scheme allows the port number to be explicitly included 1. If the URI scheme allows the port number to be explicitly
in the URI string, and a port number is not specified within the included in the URI string, and a port number is specified
within the URI, then that port number MUST be used by the client
to contact the IPP object.
Isaacson, Powell Expires May 16, 1999 2. If the URI scheme allows the port number to be explicitly
URI, then default port number implied by that URI scheme MUST be included in the URI string, and a port number is not specified
used by the client to contact the IPP object. within the URI, then default port number implied by that URI
scheme MUST be used by the client to contact the IPP object.
3. If the URI scheme does not allow an explicit port number to be 3. If the URI scheme does not allow an explicit port number to be
specified within the URI, then the default port number implied by specified within the URI, then the default port number implied
that URI MUST be used by the client to contact the IPP object. by that URI MUST be used by the client to contact the IPP
object.
Note: The IPP encoding and transport document [IPP-PRO] shows a mapping Note: The IPP encoding and transport document [RFC2565] shows a
of IPP onto HTTP/1.1 and defines a new default port number for using IPP mapping of IPP onto HTTP/1.1 and defines a new default port number
over HTTP/1.1. for using IPP over HTTP/1.1.
3.1.6 Operation Status Codes and Messages 3.1.6 Operation Status Codes and Messages
Every operation response includes a REQUIRED "status-code" parameter and Every operation response includes a REQUIRED "status-code" parameter
an OPTIONAL "status-message" operation attribute. The "status-code" and an OPTIONAL "status-message" operation attribute. The "status-
provides information on the processing of a request. A "status-message" code" provides information on the processing of a request. A
attribute provides a short textual description of the status of the "status-message" attribute provides a short textual description of
operation. The status code is intended for use by automata, and the the status of the operation. The status code is intended for use by
status message is intended for the human end user. If a response does automata, and the status message is intended for the human end user.
include a "status-message" attribute, an IPP client NEED NOT examine or If a response does include a "status-message" attribute, an IPP
display the message, however it SHOULD do so in some implementation client NEED NOT examine or display the message, however it SHOULD do
specific manner. so in some implementation specific manner.
The "status-code" value is a numeric value that has semantic meaning. The "status-code" value is a numeric value that has semantic meaning.
The "status-code" syntax is similar to a "type2 enum" (see section 4.1 The "status-code" syntax is similar to a "type2 enum" (see section
on "Attribute Syntaxes") except that values can range only from 0x0000 4.1 on "Attribute Syntaxes") except that values can range only from
to 0x7FFF. Section 14 describes the status codes, assigns the numeric 0x0000 to 0x7FFF. Section 13 describes the status codes, assigns the
values, and suggests a corresponding status message for each status numeric values, and suggests a corresponding status message for each
code. The "status-message" attribute's syntax is "text(255)". A client status code. The "status-message" attribute's syntax is "text(255)".
implementation of IPP SHOULD convert status code values into any A client implementation of IPP SHOULD convert status code values into
localized message that has semantic meaning to the end user. any localized message that has semantic meaning to the end user.
If the Printer object supports the "status-message" operation attribute, If the Printer object supports the "status-message" operation
the Printer object MUST be able to generate this message in any of the attribute, the Printer object MUST be able to generate this message
natural languages identified by the Printer object's "generated-natural- in any of the natural languages identified by the Printer object's
language-supported" attribute (see the "attributes-natural-language" "generated-natural-language-supported" attribute (see the
operation attribute specified in section 3.1.4.1). As described in "attributes-natural-language" operation attribute specified in
section 3.1.4.1 for any returned 'text' attribute, if there is a choice section 3.1.4.1). As described in section 3.1.4.1 for any returned '
for generating this message, the Printer object uses the natural text' attribute, if there is a choice for generating this message,
language indicated by the value of the "attributes-natural-language" in the Printer object uses the natural language indicated by the value
the client request if supported, otherwise the Printer object uses the of the "attributes-natural-language" in the client request if
value in the Printer object's own "natural-language-configured" supported, otherwise the Printer object uses the value in the Printer
attribute. If the Printer object supports the "status-message" object's own "natural-language-configured" attribute. If the Printer
operation attribute, it SHOULD use the REQUIRED 'utf-8' charset to object supports the "status-message" operation attribute, it SHOULD
return a status message for the following error status codes (see use the REQUIRED 'utf-8' charset to return a status message for the
section 14): 'client-error-bad-request', 'client-error-charset-not- following error status codes (see section 13): 'client-error-bad-
supported', 'server-error-internal-error', 'server-error-operation-not- request', 'client-error-charset-not-supported', 'server-error-
supported', and 'server-error-version-not-supported'. In this case, it internal-error', 'server-error-operation-not-supported', and '
MUST set the value of the "attributes-charset" operation attribute to server-error-version-not-supported'. In this case, it MUST set the
'utf-8' in the error response. value of the "attributes-charset" operation attribute to 'utf-8' in
the error response.
Isaacson, Powell Expires May 16, 1999
3.1.7 Versions 3.1.7 Versions
Each operation request and response carries with it a "version-number" Each operation request and response carries with it a "version-
parameter. Each value of the "version-number" is in the form "X.Y" number" parameter. Each value of the "version-number" is in the form
where X is the major version number and Y is the minor version number. "X.Y" where X is the major version number and Y is the minor version
By including a version number in the client request, it allows the number. By including a version number in the client request, it
client to identify which version of IPP it is interested in using. If allows the client to identify which version of IPP it is interested
the IPP object does not support that version, the object responds with a in using. If the IPP object does not support that version, the
status code of 'server-error-version-not-supported' along with the object responds with a status code of 'server-error-version-not-
closest version number that is supported (see section 14.1.5.4). supported' along with the closest version number that is supported
(see section 13.1.5.4).
There is no version negotiation per se. However, if after receiving a
'server-error-version-not-supported' status code from an IPP object,
there is nothing that prevents a client from trying again with a
different version number. In order to conform to IPP/1.0, an
implementation MUST support at least version '1.0'.
There is only one notion of "version number" that covers both IPP Model There is no version negotiation per se. However, if after receiving
and IPP Protocol changes. Thus the version number MUST change when a 'server-error-version-not-supported' status code from an IPP
introducing a new version of the Model and Semantics document [IPP-MOD] object, there is nothing that prevents a client from trying again
or a new version of the Encoding and Transport document [IPP-PRO]. with a different version number. In order to conform to IPP/1.0, an
implementation MUST support at least version '1.0'.
Changes to the major version number indicate structural or syntactic There is only one notion of "version number" that covers both IPP
changes that make it impossible for older version of IPP clients and Model and IPP Protocol changes. Thus the version number MUST change
Printer objects to correctly parse and process the new or changed when introducing a new version of the Model and Semantics document
attributes, operations and responses. If the major version number [RFC2566] or a new version of the Encoding and Transport document
changes, the minor version numbers is set to zero. As an example, [RFC2565].
adding the "ipp-attribute-fidelity" attribute (if it had not been part
of version '1.0'), would have required a change to the major version
number. Items that might affect the changing of the major version
number include any changes to the Model and Semantics document [IPP-MOD]
or the Encoding and Transport [IPP-PRO] itself, such as:
- reordering of ordered attributes or attribute sets Changes to the major version number indicate structural or syntactic
- changes to the syntax of existing attributes changes that make it impossible for older version of IPP clients and
- changing Operation or Job Template attributes from OPTIONAL to Printer objects to correctly parse and process the new or changed
REQUIRED and vice versa attributes, operations and responses. If the major version number
- adding REQUIRED (for an IPP object to support) operation attributes changes, the minor version numbers is set to zero. As an example,
- adding REQUIRED (for an IPP object to support) operation attribute adding the "ipp-attribute-fidelity" attribute (if it had not been
groups part of version '1.0'), would have required a change to the major
- adding values to existing operation attributes version number. Items that might affect the changing of the major
- adding REQUIRED operations version number include any changes to the Model and Semantics
document [RFC2566] or the Encoding and Transport [RFC2565] itself,
such as:
Changes to the minor version number indicate the addition of new - reordering of ordered attributes or attribute sets
features, attributes and attribute values that may not be understood by - changes to the syntax of existing attributes
all IPP objects, but which can be ignored if not understood. Items that - changing Operation or Job Template attributes from OPTIONAL to
might affect the changing of the minor version number include any REQUIRED and vice versa
changes to the model objects and attributes but not the encoding and - adding REQUIRED (for an IPP object to support) operation
transport rules [IPP-PRO] (except adding attribute syntaxes). Examples attributes
of such changes are: - adding REQUIRED (for an IPP object to support) operation
attribute groups
- adding values to existing operation attributes
- adding REQUIRED operations
- grouping all extensions not included in a previous version into a Changes to the minor version number indicate the addition of new
new version features, attributes and attribute values that may not be understood
- adding new attribute values by all IPP objects, but which can be ignored if not understood.
Items that might affect the changing of the minor version number
include any changes to the model objects and attributes but not the
encoding and transport rules [RFC2565] (except adding attribute
syntaxes). Examples of such changes are:
Isaacson, Powell Expires May 16, 1999 - grouping all extensions not included in a previous version into
- adding new object attributes a new version
- adding OPTIONAL (for an IPP object to support) operation attributes - adding new attribute values
(i.e., those attributes that an IPP object can ignore without - adding new object attributes
confusing clients) - adding OPTIONAL (for an IPP object to support) operation
- adding OPTIONAL (for an IPP object to support) operation attribute attributes (i.e., those attributes that an IPP object can ignore
groups (i.e., those attributes that an IPP object can ignore without confusing clients)
without confusing clients) - adding OPTIONAL (for an IPP object to support) operation
- adding new attribute syntaxes attribute groups (i.e., those attributes that an IPP object can
- adding OPTIONAL operations ignore without confusing clients)
- changing Job Description attributes or Printer Description - adding new attribute syntaxes
attributes from OPTIONAL to REQUIRED or vice versa. - adding OPTIONAL operations
- changing Job Description attributes or Printer Description
attributes from OPTIONAL to REQUIRED or vice versa.
The encoding of the "operation-id", the "version-number", the "status- The encoding of the "operation-id", the "version-number", the
code", and the "request-id" MUST NOT change over any version number "status-code", and the "request-id" MUST NOT change over any version
(either major or minor). This rule guarantees that all future versions number (either major or minor). This rule guarantees that all future
will be backwards compatible with all previous versions (at least for versions will be backwards compatible with all previous versions (at
checking the "operation-id", the "version-number", and the "request- least for checking the "operation-id", the "version-number", and the
id"). In addition, any protocol elements (attributes, error codes, "request-id"). In addition, any protocol elements (attributes, error
tags, etc.) that are not carried forward from one version to the next codes, tags, etc.) that are not carried forward from one version to
are deprecated so that they can never be reused with new semantics. the next are deprecated so that they can never be reused with new
semantics.
Implementations that support a certain major version NEED NOT support Implementations that support a certain major version NEED NOT support
ALL previous versions. As each new major version is defined (through ALL previous versions. As each new major version is defined (through
the release of a new specification), that major version will specify the release of a new specification), that major version will specify
which previous major versions MUST be supported in compliant which previous major versions MUST be supported in compliant
implementations. implementations.
3.1.8 Job Creation Operations 3.1.8 Job Creation Operations
In order to "submit a print job" and create a new Job object, a client In order to "submit a print job" and create a new Job object, a
issues a create request. A create request is any one of following three client issues a create request. A create request is any one of
operation requests: following three operation requests:
- The Print-Job Request: A client that wants to submit a print job
with only a single document uses the Print-Job operation. The
operation allows for the client to "push" the document data to the
Printer object by including the document data in the request
itself.
- The Print-URI Request: A client that wants to submit a print job - The Print-Job Request: A client that wants to submit a print job
with only a single document (where the Printer object "pulls" the with only a single document uses the Print-Job operation. The
document data instead of the client "pushing" the data to the operation allows for the client to "push" the document data to
Printer object) uses the Print-URI operation. In this case, the the Printer object by including the document data in the request
client includes in the request only a URI reference to the document itself.
data (not the document data itself).
- The Create-Job Request: A client that wants to submit a print job - The Print-URI Request: A client that wants to submit a print job
with multiple documents uses the Create-Job operation. This with only a single document (where the Printer object "pulls" the
operation is followed by an arbitrary number of Send-Document document data instead of the client "pushing" the data to the
and/or Send-URI operations (each creating another document for the Printer object) uses the Print-URI operation. In this case, the
newly create Job object). The Send-Document operation includes the client includes in the request only a URI reference to the
document data in the request (the client "pushes" the document data document data (not the document data itself).
to the printer), and the Send-URI operation includes only a URI
Isaacson, Powell Expires May 16, 1999 - The Create-Job Request: A client that wants to submit a print job
reference to the document data in the request (the Printer "pulls" with multiple documents uses the Create-Job operation. This
the document data from the referenced location). The last Send- operation is followed by an arbitrary number of Send-Document
Document or Send-URI request for a given Job object includes a and/or Send-URI operations (each creating another document for
"last-document" operation attribute set to 'true' indicating that the newly create Job object). The Send-Document operation
this is the last request. includes the document data in the request (the client "pushes"
the document data to the printer), and the Send-URI operation
includes only a URI reference to the document data in the request
(the Printer "pulls" the document data from the referenced
location). The last Send-Document or Send-URI request for a
given Job object includes a "last-document" operation attribute
set to 'true' indicating that this is the last request.
Throughout this model specification, the term "create request" is used Throughout this model specification, the term "create request" is
to refer to any of these three operation requests. used to refer to any of these three operation requests.
A Create-Job operation followed by only one Send-Document operation is A Create-Job operation followed by only one Send-Document operation
semantically equivalent to a Print-Job operation, however, for is semantically equivalent to a Print-Job operation, however, for
performance reasons, the client SHOULD use the Print-Job operation for performance reasons, the client SHOULD use the Print-Job operation
all single document jobs. Also, Print-Job is a REQUIRED operation (all for all single document jobs. Also, Print-Job is a REQUIRED
implementations MUST support it) whereas Create-Job is an OPTIONAL operation (all implementations MUST support it) whereas Create-Job is
operation, hence some implementations might not support it. an OPTIONAL operation, hence some implementations might not support
it.
Job submission time is the point in time when a client issues a create Job submission time is the point in time when a client issues a
request. The initial state of every Job object is the 'pending' or create request. The initial state of every Job object is the '
'pending-held' state. Later, the Printer object begins processing the pending' or 'pending-held' state. Later, the Printer object begins
print job. At this point in time, the Job object's state moves to processing the print job. At this point in time, the Job object's
'processing'. This is known as job processing time. There are state moves to 'processing'. This is known as job processing time.
validation checks that must be done at job submission time and others There are validation checks that must be done at job submission time
that must be performed at job processing time. and others that must be performed at job processing time.
At job submission time and at the time a Validate-Job operation is At job submission time and at the time a Validate-Job operation is
received, the Printer MUST do the following: received, the Printer MUST do the following:
1. Process the client supplied attributes and either accept or reject 1. Process the client supplied attributes and either accept or
the request reject the request
2. Validate the syntax of and support for the scheme of any client 2. Validate the syntax of and support for the scheme of any client
supplied URI supplied URI
At job submission time the Printer object MUST validate whether or not At job submission time the Printer object MUST validate whether or
the supplied attributes, attribute syntaxes, and values are supported by not the supplied attributes, attribute syntaxes, and values are
matching them with the Printer object's corresponding "xxx-supported" supported by matching them with the Printer object's corresponding
attributes. See section 3.2.1.2 for details. [IPP-IIG] presents "xxx-supported" attributes. See section 3.2.1.2 for details. [ipp-
suggested steps for an IPP object to either accept or reject any request iig] presents suggested steps for an IPP object to either accept or
and additional steps for processing create requests. reject any request and additional steps for processing create
requests.
At job submission time the Printer object NEED NOT perform the At job submission time the Printer object NEED NOT perform the
validation checks reserved for job processing time such as: validation checks reserved for job processing time such as:
1. Validating the document data 1. Validating the document data
2. Validating the actual contents of any client supplied URI (resolve 2. Validating the actual contents of any client supplied URI
the reference and follow the link to the document data) (resolve the reference and follow the link to the document data)
At job submission time, these additional job processing time validation At job submission time, these additional job processing time
checks are essentially useless, since they require actually parsing and validation checks are essentially useless, since they require
interpreting the document data, are not guaranteed to be 100% accurate, actually parsing and interpreting the document data, are not
and MUST be done, yet again, at job processing time. Also, in the case guaranteed to be 100% accurate, and MUST be done, yet again, at job
of a URI, checking for availability at job submission time does not processing time. Also, in the case of a URI, checking for
guarantee availability at job processing time. In addition, at job availability at job submission time does not guarantee availability
processing time, the Printer object might discover any of the following at job processing time. In addition, at job processing time, the
conditions that were not detectable at job submission time: Printer object might discover any of the following conditions that
were not detectable at job submission time:
Isaacson, Powell Expires May 16, 1999 - runtime errors in the document data,
- runtime errors in the document data, - nested document data that is in an unsupported format,
- nested document data that is in an unsupported format, - the URI reference is no longer valid (i.e., the server hosting
- the URI reference is no longer valid (i.e., the server hosting the the document might be down), or
document might be down), or - any other job processing error
- any other job processing error
At job processing time, since the Printer object has already responded At job processing time, since the Printer object has already
with a successful status code in the response to the create request, if responded with a successful status code in the response to the create
the Printer object detects an error, the Printer object is unable to request, if the Printer object detects an error, the Printer object
inform the end user of the error with an operation status code. In is unable to inform the end user of the error with an operation
this case, the Printer, depending on the error, can set the "job-state", status code. In this case, the Printer, depending on the error, can
"job-state-reasons", or "job-state-message" attributes to the set the "job-state", "job-state-reasons", or "job-state-message"
appropriate value(s) so that later queries can report the correct job attributes to the appropriate value(s) so that later queries can
status. report the correct job status.
Note: Asynchronous notification of events is outside the scope of Note: Asynchronous notification of events is outside the scope of
IPP/1.0. IPP/1.0.
3.2 Printer Operations 3.2 Printer Operations
All Printer operations are directed at Printer objects. A client MUST All Printer operations are directed at Printer objects. A client
always supply the "printer-uri" operation attribute in order to identify MUST always supply the "printer-uri" operation attribute in order to
the correct target of the operation. identify the correct target of the operation.
3.2.1 Print-Job Operation 3.2.1 Print-Job Operation
This REQUIRED operation allows a client to submit a print job with only This REQUIRED operation allows a client to submit a print job with
one document and supply the document data (rather than just a reference only one document and supply the document data (rather than just a
to the data). See Section 16 for the suggested steps for processing reference to the data). See Section 15 for the suggested steps for
create operations and their Operation and Job Template attributes. processing create operations and their Operation and Job Template
attributes.
3.2.1.1 Print-Job Request 3.2.1.1 Print-Job Request
The following groups of attributes are supplied as part of the Print-Job The following groups of attributes are supplied as part of the
Request: Print-Job Request:
Group 1: Operation Attributes
Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1. The Printer object
MUST copy these values to the corresponding Job Description
attributes described in sections 4.3.23 and 4.3.24.
Target:
The "printer-uri" (uri) operation attribute which is the target for
this operation as described in section 3.1.5.
Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
by the client as described in section 8.3.
Isaacson, Powell Expires May 16, 1999 Group 1: Operation Attributes
"job-name" (name(MAX)): Natural Language and Character Set:
The client OPTIONALLY supplies this attribute. The Printer object The "attributes-charset" and "attributes-natural-language"
MUST support this attribute. It contains the client supplied Job attributes as described in section 3.1.4.1. The Printer object
name. If this attribute is supplied by the client, its value is MUST copy these values to the corresponding Job Description
used for the "job-name" attribute of the newly created Job object. attributes described in sections 4.3.23 and 4.3.24.
The client MAY automatically include any information that will help
the end-user distinguish amongst his/her jobs, such as the name of
the application program along with information from the document,
such as the document name, document subject, or source file name.
If this attribute is not supplied by the client, the Printer
generates a name to use in the "job-name" attribute of the newly
created Job object (see Section 4.3.5).
"ipp-attribute-fidelity" (boolean): Target:
The client OPTIONALLY supplies this attribute. The Printer object The "printer-uri" (uri) operation attribute which is the target
MUST support this attribute. The value 'true' indicates that total for this operation as described in section 3.1.5.
fidelity to client supplied Job Template attributes and values is
required, else the Printer object MUST reject the Print-Job
request. The value 'false' indicates that a reasonable attempt to
print the Job object is acceptable and the Printer object MUST
accept the Print-job request. If not supplied, the Printer object
assumes the value is 'false'. All Printer objects MUST support
both types of job processing. See section 16 for a full
description of "ipp-attribute-fidelity" and its relationship to
other attributes, especially the Printer object's "pdl-override-
supported" attribute.
"document-name" (name(MAX)): Requesting User Name:
The client OPTIONALLY supplies this attribute. The Printer object The "requesting-user-name" (name(MAX)) attribute SHOULD be
MUST support this attribute. It contains the client supplied supplied by the client as described in section 8.3.
document name. The document name MAY be different than the Job
name. Typically, the client software automatically supplies the
document name on behalf of the end user by using a file name or an
application generated name. If this attribute is supplied, its
value can be used in a manner defined by each implementation.
Examples include: printed along with the Job (job start sheet, page
adornments, etc.), used by accounting or resource tracking
management tools, or even stored along with the document as a
document level attribute. IPP/1.0 does not support the concept of
document level attributes.
"document-format" (mimeMediaType) : "job-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. The value of this attribute object MUST support this attribute. It contains the client
identifies the format of the supplied document data. If the client supplied Job name. If this attribute is supplied by the client,
does not supply this attribute, the Printer object assumes that the its value is used for the "job-name" attribute of the newly
document data is in the format defined by the Printer object's created Job object. The client MAY automatically include any
"document-format-default" attribute. If the client supplies this information that will help the end-user distinguish amongst
attribute, but the value is not supported by the Printer object, his/her jobs, such as the name of the application program along
i.e., the value is not one of the values of the Printer object's with information from the document, such as the document name,
"document-format-supported" attribute, the Printer object MUST document subject, or source file name. If this attribute is not
reject the request and return the 'client-error-document-format- supplied by the client, the Printer generates a name to use in
not-supported' status code. the "job-name" attribute of the newly created Job object (see
Section 4.3.5).
Isaacson, Powell Expires May 16, 1999 "ipp-attribute-fidelity" (boolean):
The client OPTIONALLY supplies this attribute. The Printer
object MUST support this attribute. The value 'true' indicates
that total fidelity to client supplied Job Template attributes
and values is required, else the Printer object MUST reject the
Print-Job request. The value 'false' indicates that a
reasonable attempt to print the Job object is acceptable and the
Printer object MUST accept the Print-job request. If not
supplied, the Printer object assumes the value is 'false'. All
Printer objects MUST support both types of job processing. See
section 15 for a full description of "ipp-attribute-fidelity"
and its relationship to other attributes, especially the Printer
object's "pdl-override-supported" attribute.
"document-natural-language" (naturalLanguage): "document-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute. This attribute specifies the object MUST support this attribute. It contains the client
natural language of the document for those document-formats that supplied document name. The document name MAY be different than
require a specification of the natural language in order to image the Job name. Typically, the client software automatically
the document unambiguously. There are no particular values required supplies the document name on behalf of the end user by using a
for the Printer object to support. file name or an application generated name. If this attribute
is supplied, its value can be used in a manner defined by each
implementation. Examples include: printed along with the Job
(job start sheet, page adornments, etc.), used by accounting or
resource tracking management tools, or even stored along with
the document as a document level attribute. IPP/1.0 does not
support the concept of document level attributes.
"compression" (type3 keyword) "document-format" (mimeMediaType) :
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute and the "compression-supported" object MUST support this attribute. The value of this attribute
attribute (see section 4.4.29). The client supplied "compression" identifies the format of the supplied document data. If the
operation attribute identifies the compression algorithm used on client does not supply this attribute, the Printer object
the document data. If the client omits this attribute, the Printer assumes that the document data is in the format defined by the
object MUST assume that the data is not compressed. If the client Printer object's "document-format-default" attribute. If the
supplies the attribute and the Printer object supports the client supplies this attribute, but the value is not supported
attribute, the Printer object uses the corresponding decompression by the Printer object, i.e., the value is not one of the values
algorithm on the document data. If the client supplies this of the Printer object's "document-format-supported" attribute,
attribute, but the value is not supported by the Printer object, the Printer object MUST reject the request and return the '
i.e., the value is not one of the values of the Printer object's client-error-document-format-not-supported' status code.
"compression-supported" attribute, the Printer object MUST copy the
attribute and its value to the Unsupported Attributes response
group, reject the request, and return the 'client-error-attributes-
or-values-not-supported' status code.
"job-k-octets" (integer(0:MAX)) "document-natural-language" (naturalLanguage):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute and the "job-k-octets-supported" object OPTIONALLY supports this attribute. This attribute
attribute (see section 4.4.30). The client supplied "job-k-octets" specifies the natural language of the document for those
operation attribute identifies the total size of the document(s) in document-formats that require a specification of the natural
K octets being submitted (see section 4.3.17 for the complete language in order to image the document unambiguously. There are
semantics). If the client supplies the attribute and the Printer no particular values required for the Printer object to support.
object supports the attribute, the value of the attribute is used
to populate the Job object's "job-k-octets" Job Description
attribute.
Note: For this attribute and the following two attributes ("job- "compression" (type3 keyword)
impressions", and "job-media-sheets"), if the client supplies the The client OPTIONALLY supplies this attribute. The Printer
attribute, but the Printer object does not support the attribute, object OPTIONALLY supports this attribute and the "compression-
the Printer object ignores the client-supplied value. If the supported" attribute (see section 4.4.29). The client supplied
client supplies the attribute and the Printer supports the "compression" operation attribute identifies the compression
attribute, and the value is within the range of the corresponding algorithm used on the document data. If the client omits this
Printer object's "xxx-supported" attribute, the Printer object MUST attribute, the Printer object MUST assume that the data is not
use the value to populate the Job object's "xxx" attribute. If the compressed. If the client supplies the attribute and the
client supplies the attribute and the Printer supports the Printer object supports the attribute, the Printer object uses
attribute, but the value is outside the range of the corresponding the corresponding decompression algorithm on the document data.
Printer object's "xxx-supported" attribute, the Printer object MUST If the client supplies this attribute, but the value is not
copy the attribute and its value to the Unsupported Attributes supported by the Printer object, i.e., the value is not one of
response group, reject the request, and return the 'client-error- the values of the Printer object's "compression-supported"
attributes-or-values-not-supported' status code. If the client attribute, the Printer object MUST copy the attribute and its
does not supply the attribute, the Printer object MAY choose to value to the Unsupported Attributes response group, reject the
populate the corresponding Job object attribute depending on request, and return the 'client-error-attributes-or-values-not-
whether the Printer object supports the attribute and is able to supported' status code.
calculate or discern the correct value.
Isaacson, Powell Expires May 16, 1999 "job-k-octets" (integer(0:MAX))
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-k-
octets-supported" attribute (see section 4.4.30). The client
supplied "job-k-octets" operation attribute identifies the total
size of the document(s) in K octets being submitted (see section
4.3.17 for the complete semantics). If the client supplies the
attribute and the Printer object supports the attribute, the
value of the attribute is used to populate the Job object's
"job-k-octets" Job Description attribute.
"job-impressions" (integer(0:MAX)) Note: For this attribute and the following two attributes
The client OPTIONALLY supplies this attribute. The Printer object ("job-impressions", and "job-media-sheets"), if the client
OPTIONALLY supports this attribute and the "job-impressions- supplies the attribute, but the Printer object does not support
supported" attribute (see section 4.4.31). The client supplied the attribute, the Printer object ignores the client-supplied
"job-impressions" operation attribute identifies the total size in value. If the client supplies the attribute and the Printer
number of impressions of the document(s) being submitted (see supports the attribute, and the value is within the range of the
section 4.3.18 for the complete semantics). corresponding Printer object's "xxx-supported" attribute, the
Printer object MUST use the value to populate the Job object's
"xxx" attribute. If the client supplies the attribute and the
Printer supports the attribute, but the value is outside the
range of the corresponding Printer object's "xxx-supported"
attribute, the Printer object MUST copy the attribute and its
value to the Unsupported Attributes response group, reject the
request, and return the 'client-error-attributes-or-values-not-
supported' status code. If the client does not supply the
attribute, the Printer object MAY choose to populate the
corresponding Job object attribute depending on whether the
Printer object supports the attribute and is able to calculate
or discern the correct value.
See note under "job-k-octets". "job-impressions" (integer(0:MAX))
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-
impressions-supported" attribute (see section 4.4.31). The
client supplied "job-impressions" operation attribute identifies
the total size in number of impressions of the document(s) being
submitted (see section 4.3.18 for the complete semantics).
"job-media-sheets" (integer(0:MAX)) See note under "job-k-octets".
The client OPTIONALLY supplies this attribute. The Printer object
OPTIONALLY supports this attribute and the "job-media-sheets-
supported" attribute (see section 4.4.32). The client supplied
"job-media-sheets" operation attribute identifies the total number
of media sheets to be produced for this job (see section 4.3.19 for
the complete semantics).
See note under "job-k-octets". "job-media-sheets" (integer(0:MAX))
The client OPTIONALLY supplies this attribute. The Printer
object OPTIONALLY supports this attribute and the "job-media-
sheets-supported" attribute (see section 4.4.32). The client
supplied "job-media-sheets" operation attribute identifies the
total number of media sheets to be produced for this job (see
section 4.3.19 for the complete semantics).
Group 2: Job Template Attributes See note under "job-k-octets".
The client OPTIONALLY supplies a set of Job Template attributes as Group 2: Job Template Attributes
defined in section 4.2. If the client is not supplying any Job
Template attributes in the request, the client SHOULD omit Group 2
rather than sending an empty group. However, a Printer object MUST
be able to accept an empty group.
Group 3: Document Content The client OPTIONALLY supplies a set of Job Template attributes
as defined in section 4.2. If the client is not supplying any
Job Template attributes in the request, the client SHOULD omit
Group 2 rather than sending an empty group. However, a Printer
object MUST be able to accept an empty group.
The client MUST supply the document data to be processed. Group 3: Document Content
Note: In addition to the MANDATORY parameters required for every The client MUST supply the document data to be processed.
operation request, the simplest Print-Job Request consists of just the
"attributes-charset" and "attributes-natural-language" operation
attributes; the "printer-uri" target operation attribute; the Document
Content and nothing else. In this simple case, the Printer object:
- creates a new Job object (the Job object contains a single Note: In addition to the MANDATORY parameters required for every
document), operation request, the simplest Print-Job Request consists of just
- stores a generated Job name in the "job-name" attribute in the the "attributes-charset" and "attributes-natural-language" operation
natural language and charset requested (see Section 3.1.4.1) (if attributes; the "printer-uri" target operation attribute; the
those are supported, otherwise using the Printer object's default Document Content and nothing else. In this simple case, the Printer
natural language and charset), and object:
- at job processing time, uses its corresponding default value
attributes for the supported Job Template attributes that were not
supplied by the client as IPP attribute or embedded instructions in
the document data.
Isaacson, Powell Expires May 16, 1999 - creates a new Job object (the Job object contains a single
document),
- stores a generated Job name in the "job-name" attribute in the
natural language and charset requested (see Section 3.1.4.1) (if
those are supported, otherwise using the Printer object's default
natural language and charset), and
- at job processing time, uses its corresponding default value
attributes for the supported Job Template attributes that were
not supplied by the client as IPP attribute or embedded
instructions in the document data.
3.2.1.2 Print-Job Response 3.2.1.2 Print-Job Response
The Printer object MUST return to the client the following sets of The Printer object MUST return to the client the following sets
attributes as part of the Print-Job Response: of attributes as part of the Print-Job Response:
Group 1: Operation Attributes
Status Message:
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text)
operation attribute as described in sections 14 and 3.1.6. If the
client supplies unsupported or conflicting Job Template attributes
or values, the Printer object MUST reject or accept the Print-Job
request depending on the whether the client supplied a 'true' or
'false' value for the "ipp-attribute-fidelity" operation attribute.
See the Implementer's Guide [IPP-IIG] for a complete description of
the suggested steps for processing a create request.
Natural Language and Character Set: Group 1: Operation Attributes
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes Status Message:
In addition to the REQUIRED status code returned in every
response, the response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 14 and
3.1.6. If the client supplies unsupported or conflicting Job
Template attributes or values, the Printer object MUST reject or
accept the Print-Job request depending on the whether the client
supplied a 'true' or 'false' value for the "ipp-attribute-
fidelity" operation attribute. See the Implementer's Guide
[ipp-iig] for a complete description of the suggested steps for
processing a create request.
This is a set of Operation and Job Template attributes supplied by Natural Language and Character Set:
the client (in the request) that are not supported by the Printer The "attributes-charset" and "attributes-natural-language"
object or that conflict with one another (see the Implementer's attributes as described in section 3.1.4.2.
Guide [IPP-IIG]). If the Printer object is not returning any
Unsupported Attributes in the response, the Printer object SHOULD
omit Group 2 rather than sending an empty group. However, a client
MUST be able to accept an empty group.
Unsupported attributes fall into three categories: Group 2: Unsupported Attributes
1. The Printer object does not support the supplied attribute (no This is a set of Operation and Job Template attributes supplied
matter what the attribute syntax or value). by the client (in the request) that are not supported by the
2. The Printer object does support the attribute, but does not Printer object or that conflict with one another (see the
support some or all of the particular attribute syntaxes or Implementer's Guide [ipp-iig]). If the Printer object is not
values supplied by the client (i.e., the Printer object does returning any Unsupported Attributes in the response, the
not have those attribute syntaxes or values in its Printer object SHOULD omit Group 2 rather than sending an empty
corresponding "xxx-supported" attribute). group. However, a client MUST be able to accept an empty group.
3. The Printer object does support the attributes and values
supplied, but the particular values are in conflict with one
another, because they violate a constraint, such as not being
able to staple transparencies.
In the case of an unsupported attribute name, the Printer object Unsupported attributes fall into three categories:
returns the client-supplied attribute with a substituted "out-of-
band" value of 'unsupported' indicating no support for the
attribute itself (see the beginning of section 4.1).
In the case of a supported attribute with one or more unsupported 1. The Printer object does not support the supplied attribute
attribute syntaxes or values, the Printer object simply returns the (no matter what the attribute syntax or value).
client-supplied attribute with the unsupported attribute syntaxes 2. The Printer object does support the attribute, but does not
support some or all of the particular attribute syntaxes or
values supplied by the client (i.e., the Printer object does
not have those attribute syntaxes or values in its
corresponding "xxx-supported" attribute).
3. The Printer object does support the attributes and values
supplied, but the particular values are in conflict with one
another, because they violate a constraint, such as not being
able to staple transparencies.
Isaacson, Powell Expires May 16, 1999 In the case of an unsupported attribute name, the Printer object
or values as supplied by the client. This indicates support for returns the client-supplied attribute with a substituted "out-
the attribute, but no support for that particular attribute syntax of-band" value of 'unsupported' indicating no support for the
or value. If the client supplies a multi-valued attribute with attribute itself (see the beginning of section 4.1).
more than one value and the Printer object supports the attribute
but only supports a subset of the client-supplied attribute
syntaxes or values, the Printer object MUST return only those
attribute syntaxes or values that are unsupported.
In the case of two (or more) supported attribute values that are in In the case of a supported attribute with one or more
conflict with one another (although each is supported unsupported attribute syntaxes or values, the Printer object
independently, the values conflict when requested together within simply returns the client-supplied attribute with the
the same job), the Printer object MUST return all the values that unsupported attribute syntaxes or values as supplied by the
it ignores or substitutes to resolve the conflict, but not any of client. This indicates support for the attribute, but no
the values that it is still using. The choice for exactly how to support for that particular attribute syntax or value. If the
resolve the conflict is implementation dependent. See The client supplies a multi-valued attribute with more than one
Implementer's Guide [IPP-IIG] for an example. value and the Printer object supports the attribute but only
supports a subset of the client-supplied attribute syntaxes or
values, the Printer object MUST return only those attribute
syntaxes or values that are unsupported.
In these three cases, the value of the "ipp-attribute-fidelity" In the case of two (or more) supported attribute values that are
supplied by the client does not affect what the Printer object in conflict with one another (although each is supported
returns. The value of "ipp-attribute-fidelity" only affects independently, the values conflict when requested together
whether the Print-Job operation is accepted or rejected. If the within the same job), the Printer object MUST return all the
job is accepted, the client may query the job using the Get-Job- values that it ignores or substitutes to resolve the conflict,
Attributes operation requesting the unsupported attributes that but not any of the values that it is still using. The choice
were returned in the create response to see which attributes were for exactly how to resolve the conflict is implementation
ignored (not stored on the Job object) and which attributes were dependent. See The Implementer's Guide [ipp-iig] for an
stored with other (substituted) values. example.
Group 3: Job Object Attributes In these three cases, the value of the "ipp-attribute-fidelity"
supplied by the client does not affect what the Printer object
returns. The value of "ipp-attribute-fidelity" only affects
whether the Print-Job operation is accepted or rejected. If the
job is accepted, the client may query the job using the Get-
Job-Attributes operation requesting the unsupported attributes
that were returned in the create response to see which
attributes were ignored (not stored on the Job object) and which
attributes were stored with other (substituted) values.
"job-uri" (uri): Group 3: Job Object Attributes
The Printer object MUST return the Job object's URI by returning
the contents of the REQUIRED "job-uri" Job object attribute. The
client uses the Job object's URI when directing operations at the
Job object. The Printer object always uses its configured security
policy when creating the new URI. However, if the Printer object
supports more than one URI, the Printer object also uses
information about which URI was used in the Print-Job Request to
generated the new URI so that the new URI references the correct
access channel. In other words, if the Print-Job Request comes in
over a secure channel, the Printer object MUST generate a Job URI
that uses the secure channel as well.
"job-id" (integer(1:MAX)): "job-uri" (uri):
The Printer object MUST return the Job object's Job ID by returning The Printer object MUST return the Job object's URI by returning
the REQUIRED "job-id" Job object attribute. The client uses this the contents of the REQUIRED "job-uri" Job object attribute.
"job-id" attribute in conjunction with the "printer-uri" attribute The client uses the Job object's URI when directing operations
used in the Print-Job Request when directing Job operations at the at the Job object. The Printer object always uses its
Printer object. configured security policy when creating the new URI. However,
if the Printer object supports more than one URI, the Printer
object also uses information about which URI was used in the
Print-Job Request to generated the new URI so that the new URI
references the correct access channel. In other words, if the
Print-Job Request comes in over a secure channel, the Printer
object MUST generate a Job URI that uses the secure channel as
well.
"job-state": "job-id" (integer(1:MAX)):
The Printer object MUST return the Job object's REQUIRED "job- The Printer object MUST return the Job object's Job ID by
state" attribute. The value of this attribute (along with the value returning the REQUIRED "job-id" Job object attribute. The
of the next attribute "job-state-reasons") is taken from a client uses this "job-id" attribute in conjunction with the
"snapshot" of the new Job object at some meaningful point in time "printer-uri" attribute used in the Print-Job Request when
directing Job operations at the Printer object.
Isaacson, Powell Expires May 16, 1999 "job-state":
(implementation defined) between when the Printer object receives The Printer object MUST return the Job object's REQUIRED "job-
the Print-Job Request and when the Printer object returns the state" attribute. The value of this attribute (along with the
response. value of the next attribute "job-state-reasons") is taken from a
"snapshot" of the new Job object at some meaningful point in
time (implementation defined) between when the Printer object
receives the Print-Job Request and when the Printer object
returns the response.
"job-state-reasons": "job-state-reasons":
The Printer object OPTIONALLY returns the Job object's OPTIONAL The Printer object OPTIONALLY returns the Job object's OPTIONAL
"job-state-reasons" attribute. If the Printer object supports this "job-state-reasons" attribute. If the Printer object supports
attribute then it MUST be returned in the response. If this this attribute then it MUST be returned in the response. If
attribute is not returned in the response, the client can assume this attribute is not returned in the response, the client can
that the "job-state-reasons" attribute is not supported and will assume that the "job-state-reasons" attribute is not supported
not be returned in a subsequent Job object query. and will not be returned in a subsequent Job object query.
"job-state-message": "job-state-message":
The Printer object OPTIONALLY returns the Job object's OPTIONAL The Printer object OPTIONALLY returns the Job object's OPTIONAL
"job-state-message" attribute. If the Printer object supports this "job-state-message" attribute. If the Printer object supports
attribute then it MUST be returned in the response. If this this attribute then it MUST be returned in the response. If
attribute is not returned in the response, the client can assume this attribute is not returned in the response, the client can
that the "job-state-message" attribute is not supported and will assume that the "job-state-message" attribute is not supported
not be returned in a subsequent Job object query. and will not be returned in a subsequent Job object query.
"number-of-intervening-jobs": "number-of-intervening-jobs":
The Printer object OPTIONALLY returns the Job object's OPTIONAL The Printer object OPTIONALLY returns the Job object's OPTIONAL
"number-of-intervening-jobs" attribute. If the Printer object "number-of-intervening-jobs" attribute. If the Printer object
supports this attribute then it MUST be returned in the response. supports this attribute then it MUST be returned in the
If this attribute is not returned in the response, the client can response. If this attribute is not returned in the response,
assume that the "number-of-intervening-jobs" attribute is not the client can assume that the "number-of-intervening-jobs"
supported and will not be returned in a subsequent Job object attribute is not supported and will not be returned in a
query. subsequent Job object query.
Note: Since any printer state information which affects a job's Note: Since any printer state information which affects a job's
state is reflected in the "job-state" and "job-state-reasons" state is reflected in the "job-state" and "job-state-reasons"
attributes, it is sufficient to return only these attributes and no attributes, it is sufficient to return only these attributes and
specific printer status attributes. no specific printer status attributes.
Note: In addition to the MANDATORY parameters required for every Note: In addition to the MANDATORY parameters required for every
operation response, the simplest response consists of the just the operation response, the simplest response consists of the just the
"attributes-charset" and "attributes-natural-language" operation "attributes-charset" and "attributes-natural-language" operation
attributes and the "job-uri", "job-id", and "job-state" Job Object attributes and the "job-uri", "job-id", and "job-state" Job Object
Attributes. In this simplest case, the status code is "successful-ok" Attributes. In this simplest case, the status code is "successful-
and there is no "status-message" operation attribute. ok" and there is no "status-message" operation attribute.
3.2.2 Print-URI Operation 3.2.2 Print-URI Operation
This OPTIONAL operation is identical to the Print-Job operation (section This OPTIONAL operation is identical to the Print-Job operation
3.2.1) except that a client supplies a URI reference to the document (section 3.2.1) except that a client supplies a URI reference to the
data using the "document-uri" (uri) operation attribute (in Group 1) document data using the "document-uri" (uri) operation attribute (in
rather than including the document data itself. Before returning the Group 1) rather than including the document data itself. Before
response, the Printer MUST validate that the Printer supports the returning the response, the Printer MUST validate that the Printer
retrieval method (e.g., http, ftp, etc.) implied by the URI, and MUST supports the retrieval method (e.g., http, ftp, etc.) implied by the
check for valid URI syntax. If the client-supplied URI scheme is not URI, and MUST check for valid URI syntax. If the client-supplied URI
supported, i.e. the value is not in the Printer object's "referenced- scheme is not supported, i.e. the value is not in the Printer
uri-scheme-supported" attribute, the Printer object MUST reject the object's "referenced-uri-scheme-supported" attribute, the Printer
request and return the 'client-error-uri-scheme-not-supported' status object MUST reject the request and return the 'client-error-uri-
scheme-not-supported' status code. See The Implementer's Guide
Isaacson, Powell Expires May 16, 1999 [ipp-iig] for suggested additional checks. The Printer NEED NOT
code. See The Implementer's Guide [IPP-IIG] for suggested additional follow the reference and validate the contents of the reference.
checks. The Printer NEED NOT follow the reference and validate the
contents of the reference.
If the Printer object supports this operation, it MUST support the If the Printer object supports this operation, it MUST support the
"reference-uri-schemes-supported" Printer attribute (see section "reference-uri-schemes-supported" Printer attribute (see section
4.4.24). 4.4.24).
It is up to the IPP object to interpret the URI and subsequently "pull" It is up to the IPP object to interpret the URI and subsequently
the document from the source referenced by the URI string. "pull" the document from the source referenced by the URI string.
3.2.3 Validate-Job Operation 3.2.3 Validate-Job Operation
This REQUIRED operation is similar to the Print-Job operation (section This REQUIRED operation is similar to the Print-Job operation
3.2.1) except that a client supplies no document data and the Printer (section 3.2.1) except that a client supplies no document data and
allocates no resources (i.e., it does not create a new Job object). the Printer allocates no resources (i.e., it does not create a new
This operation is used only to verify capabilities of a printer object Job object). This operation is used only to verify capabilities of a
against whatever attributes are supplied by the client in the Validate- printer object against whatever attributes are supplied by the client
Job request. By using the Validate-Job operation a client can validate in the Validate-Job request. By using the Validate-Job operation a
that an identical Print-Job operation (with the document data) would be client can validate that an identical Print-Job operation (with the
accepted. The Validate-Job operation also performs the same security document data) would be accepted. The Validate-Job operation also
negotiation as the Print-Job operation (see section 8), so that a client performs the same security negotiation as the Print-Job operation
can check that the client and Printer object security requirements can (see section 8), so that a client can check that the client and
be met before performing a Print-Job operation. Printer object security requirements can be met before performing a
Print-Job operation.
Note: The Validate-Job operation does not accept a "document-uri" Note: The Validate-Job operation does not accept a "document-uri"
attribute in order to allow a client to check that the same Print-URI attribute in order to allow a client to check that the same Print-URI
operation will be accepted, since the client doesn't send the data with operation will be accepted, since the client doesn't send the data
the Print-URI operation. The client SHOULD just issue the Print-URI with the Print-URI operation. The client SHOULD just issue the
request. Print-URI request.
The Printer object returns the same status codes, Operation Attributes The Printer object returns the same status codes, Operation
(Group 1) and Unsupported Attributes (Group 2) as the Print-Job Attributes (Group 1) and Unsupported Attributes (Group 2) as the
operation. However, no Job Object Attributes (Group 3) are returned, Print-Job operation. However, no Job Object Attributes (Group 3) are
since no Job object is created. returned, since no Job object is created.
3.2.4 Create-Job Operation 3.2.4 Create-Job Operation
This OPTIONAL operation is similar to the Print-Job operation (section This OPTIONAL operation is similar to the Print-Job operation
3.2.1) except that in the Create-Job request, a client does not supply (section 3.2.1) except that in the Create-Job request, a client does
document data or any reference to document data. Also, the client does not supply document data or any reference to document data. Also,
not supply any of the "document-name", "document-format", "compression", the client does not supply any of the "document-name", "document-
or "document-natural-language" operation attributes. This operation is format", "compression", or "document-natural-language" operation
followed by one or more Send-Document or Send-URI operations. In each attributes. This operation is followed by one or more Send-Document
of those operation requests, the client OPTIONALLY supplies the or Send-URI operations. In each of those operation requests, the
"document-name", "document-format", and "document-natural-language" client OPTIONALLY supplies the "document-name", "document-format",
attributes for each document in the multi-document Job object. and "document-natural-language" attributes for each document in the
multi-document Job object.
If a Printer object supports the Create-Job operation, it MUST also
support the Send-Document operation and also MAY support the Send-URI
operation.
Isaacson, Powell Expires May 16, 1999 If a Printer object supports the Create-Job operation, it MUST also
If the Printer object supports this operation, it MUST support the support the Send-Document operation and also MAY support the Send-URI
"multiple-operation-time-out" Printer attribute (see section 4.4.28). operation.
In addition to the Print-Job status codes in the following additional If the Printer object supports this operation, it MUST support the
error status codes not applicable to Print-Job MAY be returned: "multiple-operation-time-out" Printer attribute (see section 4.4.28).
3.2.5 Get-Printer-Attributes Operation 3.2.5 Get-Printer-Attributes Operation
This REQUIRED operation allows a client to request the values of the This REQUIRED operation allows a client to request the values of the
attributes of a Printer object. In the request, the client supplies attributes of a Printer object. In the request, the client supplies
the set of Printer attribute names and/or attribute group names in which the set of Printer attribute names and/or attribute group names in
the requester is interested. In the response, the Printer object which the requester is interested. In the response, the Printer
returns a corresponding attribute set with the appropriate attribute object returns a corresponding attribute set with the appropriate
values filled in. attribute values filled in.
For Printer objects, the possible names of attribute groups are: For Printer objects, the possible names of attribute groups are:
- 'job-template': all of the Job Template attributes that apply to a - 'job-template': all of the Job Template attributes that apply to
Printer object (the last two columns of the table in Section 4.2). a Printer object (the last two columns of the table in Section
- 'printer-description': the attributes specified in Section 4.4. 4.2).
- 'all': the special group 'all' that includes all supported - 'printer-description': the attributes specified in Section 4.4.
attributes. - 'all': the special group 'all' that includes all supported
attributes.
Since a client MAY request specific attributes or named groups, there is Since a client MAY request specific attributes or named groups, there
a potential that there is some overlap. For example, if a client is a potential that there is some overlap. For example, if a client
requests, 'printer-name' and 'all', the client is actually requesting requests, 'printer-name' and 'all', the client is actually requesting
the "printer-name" attribute twice: once by naming it explicitly, and the "printer-name" attribute twice: once by naming it explicitly, and
once by inclusion in the 'all' group. In such cases, the Printer object once by inclusion in the 'all' group. In such cases, the Printer
NEED NOT return each attribute only once in the response even if it is object NEED NOT return each attribute only once in the response even
requested multiple times. The client SHOULD NOT request the same if it is requested multiple times. The client SHOULD NOT request the
attribute in multiple ways. same attribute in multiple ways.
It is NOT REQUIRED that a Printer object support all attributes It is NOT REQUIRED that a Printer object support all attributes
belonging to a group (since some attributes are OPTIONAL). However, it belonging to a group (since some attributes are OPTIONAL). However,
is REQUIRED that each Printer object support all group names. it is REQUIRED that each Printer object support all group names.
3.2.5.1 Get-Printer-Attributes Request 3.2.5.1 Get-Printer-Attributes Request
The following sets of attributes are part of the Get-Printer-Attributes The following sets of attributes are part of the Get-Printer-
Request: Attributes Request:
Group 1: Operation Attributes
Natural Language and Character Set: Group 1: Operation Attributes
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
Target: Natural Language and Character Set:
The "printer-uri" (uri) operation attribute which is the target for attributes-charset" and "attributes-natural-language" butes as
this operation as described in section 3.1.5. described in section 3.1.4.1.
Isaacson, Powell Expires May 16, 1999 Target:
The "printer-uri" (uri) operation attribute which is the target
for this operation as described in section 3.1.5.
Requesting User Name: Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied The "requesting-user-name" (name(MAX)) attribute SHOULD be
by the client as described in section 8.3. supplied by the client as described in section 8.3.
"requested-attributes" (1setOf keyword) : "requested-attributes" (1setOf keyword) :
The client OPTIONALLY supplies a set of attribute names and/or The client OPTIONALLY supplies a set of attribute names and/or
attribute group names in whose values the requester is interested. attribute group names in whose values the requester is
The Printer object MUST support this attribute. If the client interested. The Printer object MUST support this attribute. If
omits this attribute, the Printer MUST respond as if this attribute the client omits this attribute, the Printer MUST respond as if
had been supplied with a value of 'all'. this attribute had been supplied with a value of 'all'.
"document-format" (mimeMediaType) : "document-format" (mimeMediaType) :
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. This attribute is useful for a object MUST support this attribute. This attribute is useful
Printer object to determine the set of supported attribute values for a Printer object to determine the set of supported attribute
that relate to the requested document format. The Printer object values that relate to the requested document format. The
MUST return the attributes and values that it uses to validate a Printer object MUST return the attributes and values that it
job on a create or Validate-Job operation in which this document uses to validate a job on a create or Validate-Job operation in
format is supplied. The Printer object SHOULD return only (1) those which this document format is supplied. The Printer object
attributes that are supported for the specified format and (2) the SHOULD return only (1) those attributes that are supported for
attribute values that are supported for the specified document the specified format and (2) the attribute values that are
format. By specifying the document format, the client can get the supported for the specified document format. By specifying the
Printer object to eliminate the attributes and values that are not document format, the client can get the Printer object to
supported for a specific document format. For example, a Printer eliminate the attributes and values that are not supported for a
object might have multiple interpreters to support both specific document format. For example, a Printer object might
'application/postscript' (for PostScript) and 'text/plain' (for have multiple interpreters to support both '
text) documents. However, for only one of those interpreters might application/postscript' (for PostScript) and 'text/plain' (for
the Printer object be able to support "number-up" with values of text) documents. However, for only one of those interpreters
'1', '2', and '4'. For the other interpreter it might be able to might the Printer object be able to support "number-up" with
only support "number-up" with a value of '1'. Thus a client can use values of '1', '2', and '4'. For the other interpreter it might
the Get-Printer-Attributes operation to obtain the attributes and be able to only support "number-up" with a value of '1'. Thus a
values that will be used to accept/reject a create job operation. client can use the Get-Printer-Attributes operation to obtain
the attributes and values that will be used to accept/reject a
create job operation.
If the Printer object does not distinguish between different sets If the Printer object does not distinguish between different
of supported values for each different document format when sets of supported values for each different document format when
validating jobs in the create and Validate-Job operations, it MUST validating jobs in the create and Validate-Job operations, it
NOT distinguish between different document formats in the Get- MUST NOT distinguish between different document formats in the
Printer-Attributes operation. If the Printer object does Get-Printer-Attributes operation. If the Printer object does
distinguish between different sets of supported values for each distinguish between different sets of supported values for each
different document format specified by the client, this different document format specified by the client, this
specialization applies only to the following Printer object specialization applies only to the following Printer object
attributes: attributes:
- Printer attributes that are Job Template attributes ("xxx- - Printer attributes that are Job Template attributes ("xxx-
default" "xxx-supported", and "xxx-ready" in the Table in default" "xxx-supported", and "xxx-ready" in the Table in
Section 4.2), Section 4.2),
- "pdl-override-supported", - "pdl-override-supported",
- "compression-supported", - "compression-supported",
- "job-k-octets-supported", - "job-k-octets-supported",
- "job-impressions-supported, - "job-impressions-supported,
- "job-media-sheets-supported" - "job-media-sheets-supported"
- "printer-driver-installer", - "printer-driver-installer",
- "color-supported", and - "color-supported", and
- "reference-uri-schemes-supported" - "reference-uri-schemes-supported"
Isaacson, Powell Expires May 16, 1999 The values of all other Printer object attributes (including
"document-format-supported") remain invariant with respect to
The values of all other Printer object attributes (including the client supplied document format (except for new Printer
"document-format-supported") remain invariant with respect to the description attribute as registered according to section 6.2).
client supplied document format (except for new Printer description
attribute as registered according to section 6.2).
If the client omits this "document-format" operation attribute, the If the client omits this "document-format" operation attribute,
Printer object MUST respond as if the attribute had been supplied the Printer object MUST respond as if the attribute had been
with the value of the Printer object's "document-format-default" supplied with the value of the Printer object's "document-
attribute. It is recommended that the client always supply a value format-default" attribute. It is recommended that the client
for "document-format", since the Printer object's "document-format- always supply a value for "document-format", since the Printer
default" may be 'application/octet-stream', in which case the object's "document-format-default" may be 'application/octet-
returned attributes and values are for the union of the document stream', in which case the returned attributes and values are
formats that the Printer can automatically sense. For more for the union of the document formats that the Printer can
details, see the description of the 'mimeMediaType' attribute automatically sense. For more details, see the description of
syntax in section 4.1.9. the 'mimeMediaType' attribute syntax in section 4.1.9.
If the client supplies a value for the "document-format" Operation If the client supplies a value for the "document-format"
attribute that is not supported by the Printer, i.e., is not among Operation attribute that is not supported by the Printer, i.e.,
the values of the Printer object's "document-format-supported" is not among the values of the Printer object's "document-
attribute, the Printer object MUST reject the operation and return format-supported" attribute, the Printer object MUST reject the
the 'client-error-document-format-not-supported' status code. operation and return the 'client-error-document-format-not-
supported' status code.
3.2.5.2 Get-Printer-Attributes Response 3.2.5.2 Get-Printer-Attributes Response
The Printer object returns the following sets of attributes as part of The Printer object returns the following sets of attributes as part
the Get-Printer-Attributes Response: of the Get-Printer-Attributes Response:
Group 1: Operation Attributes Group 1: Operation Attributes
Status Message: Status Message:
In addition to the REQUIRED status code returned in every response, In addition to the REQUIRED status code returned in every
the response OPTIONALLY includes a "status-message" (text) response, the response OPTIONALLY includes a "status-message"
operation attribute as described in section 3.1.6. (text) operation attribute as described in section 3.1.6.
Natural Language and Character Set: Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language" The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2. attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes Group 2: Unsupported Attributes
This is a set of Operation attributes supplied by the client (in This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or that the request) that are not supported by the Printer object or
conflict with one another (see sections 3.2.1.2 and 16). The that conflict with one another (see sections 3.2.1.2 and 16).
response NEED NOT contain the "requested-attributes" operation The response NEED NOT contain the "requested-attributes"
attribute with any supplied values (attribute keywords) that were operation attribute with any supplied values (attribute
requested by the client but are not supported by the IPP object. keywords) that were requested by the client but are not
If the Printer object is not returning any Unsupported Attributes supported by the IPP object. If the Printer object is not
in the response, the Printer object SHOULD omit Group 2 rather than returning any Unsupported Attributes in the response, the
sending an empty group. However, a client MUST be able to accept Printer object SHOULD omit Group 2 rather than sending an empty
an empty group. group. However, a client MUST be able to accept an empty group.
Group 3: Printer Object Attributes Group 3: Printer Object Attributes
Isaacson, Powell Expires May 16, 1999 This is the set of requested attributes and their current
This is the set of requested attributes and their current values. values. The Printer object ignores (does not respond with) any
The Printer object ignores (does not respond with) any requested requested attribute which is not supported. The Printer object
attribute which is not supported. The Printer object MAY respond MAY respond with a subset of the supported attributes and
with a subset of the supported attributes and values, depending on values, depending on the security policy in force. However, the
the security policy in force. However, the Printer object MUST Printer object MUST respond with the 'unknown' value for any
respond with the 'unknown' value for any supported attribute supported attribute (including all REQUIRED attributes) for
(including all REQUIRED attributes) for which the Printer object which the Printer object does not know the value. Also the
does not know the value. Also the Printer object MUST respond with Printer object MUST respond with the 'no-value' for any
the 'no-value' for any supported attribute (including all REQUIRED supported attribute (including all REQUIRED attributes) for
attributes) for which the system administrator has not configured a which the system administrator has not configured a value. See
value. See the description of the "out-of-band" values in the the description of the "out-of-band" values in the beginning of
beginning of Section 4.1. Section 4.1.
3.2.6 Get-Jobs Operation 3.2.6 Get-Jobs Operation
This REQUIRED operation allows a client to retrieve the list of Job This REQUIRED operation allows a client to retrieve the list of Job
objects belonging to the target Printer object. The client may also objects belonging to the target Printer object. The client may also
supply a list of Job attribute names and/or attribute group names. A supply a list of Job attribute names and/or attribute group names. A
group of Job object attributes will be returned for each Job object that group of Job object attributes will be returned for each Job object
is returned. that is returned.
This operation is similar to the Get-Job-Attributes operation, except This operation is similar to the Get-Job-Attributes operation, except
that this Get-Jobs operation returns attributes from possibly more than that this Get-Jobs operation returns attributes from possibly more
one object (see the description of Job attribute group names in section than one object (see the description of Job attribute group names in
3.3.4). section 3.3.4).
3.2.6.1 Get-Jobs Request 3.2.6.1 Get-Jobs Request
The client submits the Get-Jobs request to a Printer object. The client submits the Get-Jobs request to a Printer object.
The following groups of attributes are part of the Get-Jobs Request:
Group 1: Operation Attributes The following groups of attributes are part of the Get-Jobs Request:
Natural Language and Character Set: Group 1: Operation Attributes
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
Target: Natural Language and Character Set:
The "printer-uri" (uri) operation attribute which is the target for The "attributes-charset" and "attributes-natural-language"
this operation as described in section 3.1.5. attributes as described in section 3.1.4.1.
Requesting User Name: Target:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied The "printer-uri" (uri) operation attribute which is the target
by the client as described in section 8.3. for this operation as described in section 3.1.5.
"limit" (integer(1:MAX)): Requesting User Name:
The client OPTIONALLY supplies this attribute. The Printer object The "requesting-user-name" (name(MAX)) attribute SHOULD be
MUST support this attribute. It is an integer value that indicates supplied by the client as described in section 8.3.
a limit to the number of Job objects returned. The limit is a
"stateless limit" in that if the value supplied by the client is
'N', then only the first 'N' jobs are returned in the Get-Jobs
Response. There is no mechanism to allow for the next 'M' jobs
Isaacson, Powell Expires May 16, 1999 "limit" (integer(1:MAX)):
after the first 'N' jobs. If the client does not supply this The client OPTIONALLY supplies this attribute. The Printer
attribute, the Printer object responds with all applicable jobs. object MUST support this attribute. It is an integer value that
indicates a limit to the number of Job objects returned. The
limit is a "stateless limit" in that if the value supplied by
the client is 'N', then only the first 'N' jobs are returned in
the Get-Jobs Response. There is no mechanism to allow for the
next 'M' jobs after the first 'N' jobs. If the client does not
supply this attribute, the Printer object responds with all
applicable jobs.
"requested-attributes" (1setOf keyword): "requested-attributes" (1setOf keyword):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. It is a set of Job attribute names object MUST support this attribute. It is a set of Job
and/or attribute groups names in whose values the requester is attribute names and/or attribute groups names in whose values
interested. This set of attributes is returned for each Job object the requester is interested. This set of attributes is returned
that is returned. The allowed attribute group names are the same for each Job object that is returned. The allowed attribute
as those defined in the Get-Job-Attributes operation in section group names are the same as those defined in the Get-Job-
3.3.4. If the client does not supply this attribute, the Printer Attributes operation in section 3.3.4. If the client does not
MUST respond as if the client had supplied this attribute with two supply this attribute, the Printer MUST respond as if the client
values: 'job-uri' and 'job-id'. had supplied this attribute with two values: 'job-uri' and '
job-id'.
"which-jobs" (keyword): "which-jobs" (type2 keyword):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. It indicates which Job objects MUST object MUST support this attribute. It indicates which Job
be returned by the Printer object. The values for this attribute objects MUST be returned by the Printer object. The values for
are: this attribute are:
'completed': This includes any Job object whose state is 'completed': This includes any Job object whose state is
'completed', 'canceled', or 'aborted'. 'completed', 'canceled', or 'aborted'.
'not-completed': This includes any Job object whose state is 'not-completed': This includes any Job object whose state is '
'pending', 'processing', 'processing-stopped', or 'pending- pending', 'processing', 'processing-stopped', or 'pending-
held'. held'.
A Printer object MUST support both values. However, if the A Printer object MUST support both values. However, if the
implementation does not keep jobs in the 'completed', 'canceled', mentation does not keep jobs in the 'completed', 'canceled', '
and 'aborted' states, then it returns no jobs when the 'completed' aborted' states, then it returns no jobs when the 'completed'
value is supplied. value is supplied.
If a client supplies some other value, the Printer object MUST copy If a client supplies some other value, the Printer object MUST
the attribute and the unsupported value to the Unsupported copy the attribute and the unsupported value to the Unsupported
Attributes response group, reject the request, and return the Attributes response group, reject the request, and return the '
'client-error-attributes-or-values-not-supported' status code. client-error-attributes-or-values-not-supported' status code.
If the client does not supply this attribute, the Printer object If the client does not supply this attribute, the Printer object
MUST respond as if the client had supplied the attribute with a MUST respond as if the client had supplied the attribute with a
value of 'not-completed'. value of 'not-completed'.
"my-jobs" (boolean): "my-jobs" (boolean):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. It indicates whether all jobs or just object MUST support this attribute. It indicates whether all
the jobs submitted by the requesting user of this request MUST be jobs or just the jobs submitted by the requesting user of this
returned by the Printer object. If the client does not supply this request MUST be returned by the Printer object. If the client
attribute, the Printer object MUST respond as if the client had does not supply this attribute, the Printer object MUST respond
supplied the attribute with a value of 'false', i.e., all jobs. as if the client had supplied the attribute with a value of '
The means for authenticating the requesting user and matching the false', i.e., all jobs. The means for authenticating the
jobs is described in section 8. requesting user and matching the jobs is described in section 8.
3.2.6.2 Get-Jobs Response 3.2.6.2 Get-Jobs Response
The Printer object returns all of the Job objects that match the The Printer object returns all of the Job objects that match the
criteria as defined by the attribute values supplied by the client in criteria as defined by the attribute values supplied by the client in
the request. It is possible that no Job objects are returned since
Isaacson, Powell Expires May 16, 1999 there may literally be no Job objects at the Printer, or there may be
the request. It is possible that no Job objects are returned since no Job objects that match the criteria supplied by the client. If
there may literally be no Job objects at the Printer, or there may be no the client requests any Job attributes at all, there is a set of Job
Job objects that match the criteria supplied by the client. If the Object Attributes returned for each Job object.
client requests any Job attributes at all, there is a set of Job Object
Attributes returned for each Job object.
Group 1: Operation Attributes
Status Message: Group 1: Operation Attributes
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text)
operation attribute as described in sections 14 and 3.1.6.
Natural Language and Character Set: Status Message:
The "attributes-charset" and "attributes-natural-language" In addition to the REQUIRED status code returned in every
attributes as described in section 3.1.4.2. response, the response OPTIONALLY includes a "status-message"
(text) operation attribute as described in sections 14 and
3.1.6.
Group 2: Unsupported Attributes Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
This is a set of Operation attributes supplied by the client (in Group 2: Unsupported Attributes
the request) that are not supported by the Printer object or that
conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [IPP-IIG]). The response NEED NOT contain the
"requested-attributes" operation attribute with any supplied values
(attribute keywords) that were requested by the client but are not
supported by the IPP object. If the Printer object is not
returning any Unsupported Attributes in the response, the Printer
object SHOULD omit Group 2 rather than sending an empty group.
However, a client MUST be able to accept an empty group.
Groups 3 to N: Job Object Attributes This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or
that conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [ipp-iig]). The response NEED NOT contain
the "requested-attributes" operation attribute with any supplied
values (attribute keywords) that were requested by the client
but are not supported by the IPP object. If the Printer object
is not returning any Unsupported Attributes in the response, the
Printer object SHOULD omit Group 2 rather than sending an empty
group. However, a client MUST be able to accept an empty group.
The Printer object responds with one set of Job Object Attributes Groups 3 to N: Job Object Attributes
for each returned Job object. The Printer object ignores (does not
respond with) any requested attribute or value which is not
supported or which is restricted by the security policy in force,
including whether the requesting user is the user that submitted
the job (job originating user) or not (see section 8). However,
the Printer object MUST respond with the 'unknown' value for any
supported attribute (including all REQUIRED attributes) for which
the Printer object does not know the value, unless it would violate
the security policy. See the description of the "out-of-band"
values in the beginning of Section 4.1.
Jobs are returned in the following order: The Printer object responds with one set of Job Object
Attributes for each returned Job object. The Printer object
ignores (does not respond with) any requested attribute or value
which is not supported or which is restricted by the security
policy in force, including whether the requesting user is the
user that submitted the job (job originating user) or not (see
section 8). However, the Printer object MUST respond with the '
unknown' value for any supported attribute (including all
REQUIRED attributes) for which the Printer object does not know
the value, unless it would violate the security policy. See the
description of the "out-of-band" values in the beginning of
Section 4.1.
- If the client requests all 'completed' Jobs (Jobs in the Jobs are returned in the following order:
'completed', 'aborted', or 'canceled' states), then the Jobs
are returned newest to oldest (with respect to actual
completion time)
- If the client requests all 'not-completed' Jobs (Jobs in the
'pending', 'processing', 'pending-held', and 'processing-
stopped' states), then Jobs are returned in relative
chronological order of expected time to complete (based on
Isaacson, Powell Expires May 16, 1999 - If the client requests all 'completed' Jobs (Jobs in the '
whatever scheduling algorithm is configured for the Printer completed', 'aborted', or 'canceled' states), then the Jobs
object). are returned newest to oldest (with respect to actual
completion time)
- If the client requests all 'not-completed' Jobs (Jobs in the
'pending', 'processing', 'pending-held', and 'processing-
stopped' states), then Jobs are returned in relative
chronological order of expected time to complete (based on
whatever scheduling algorithm is configured for the Printer
object).
3.3 Job Operations 3.3 Job Operations
All Job operations are directed at Job objects. A client MUST always All Job operations are directed at Job objects. A client MUST always
supply some means of identifying the Job object in order to identify the supply some means of identifying the Job object in order to identify
correct target of the operation. That job identification MAY either be the correct target of the operation. That job identification MAY
a single Job URI or a combination of a Printer URI with a Job ID. The either be a single Job URI or a combination of a Printer URI with a
IPP object implementation MUST support both forms of identification for Job ID. The IPP object implementation MUST support both forms of
every job. identification for every job.
3.3.1 Send-Document Operation 3.3.1 Send-Document Operation
This OPTIONAL operation allows a client to create a multi-document Job This OPTIONAL operation allows a client to create a multi-document
object that is initially "empty" (contains no documents). In the Job object that is initially "empty" (contains no documents). In the
Create-Job response, the Printer object returns the Job object's URI Create-Job response, the Printer object returns the Job object's URI
(the "job-uri" attribute) and the Job object's 32-bit identifier (the (the "job-uri" attribute) and the Job object's 32-bit identifier (the
"job-id" attribute). For each new document that the client desires to "job-id" attribute). For each new document that the client desires
add, the client uses a Send-Document operation. Each Send-Document to add, the client uses a Send-Document operation. Each Send-
Request contains the entire stream of document data for one document. Document Request contains the entire stream of document data for one
document.
Since the Create-Job and the send operations (Send-Document or Send-URI
operations) that follow could occur over an arbitrarily long period of
time for a particular job, a client MUST send another send operation
within an IPP Printer defined minimum time interval after the receipt of
the previous request for the job. If a Printer object supports multiple
document jobs, the Printer object MUST support the "multiple-operation-
time-out" attribute (see section 4.4.28). This attribute indicates the
minimum number of seconds the Printer object will wait for the next send
operation before taking some recovery action.
An IPP object MUST recover from an errant client that does not supply a Since the Create-Job and the send operations (Send-Document or Send-
send operation, sometime after the minimum time interval specified by URI operations) that follow could occur over an arbitrarily long
the Printer object's "multiple-operation-time-out" attribute. Such period of time for a particular job, a client MUST send another send
recovery MAY include any of the following or other recovery actions: operation within an IPP Printer defined minimum time interval after
the receipt of the previous request for the job. If a Printer object
supports multiple document jobs, the Printer object MUST support the
"multiple-operation-time-out" attribute (see section 4.4.28). This
attribute indicates the minimum number of seconds the Printer object
will wait for the next send operation before taking some recovery
action.
1. Assume that the Job is an invalid job, start the process of An IPP object MUST recover from an errant client that does not supply
changing the job state to 'aborted', add the 'aborted-by-system' a send operation, sometime after the minimum time interval specified
value to the job's "job-state-reasons" attribute (see section by the Printer object's "multiple-operation-time-out" attribute.
4.3.8), if supported, and clean up all resources associated with Such recovery MAY include any of the following or other recovery
the Job. In this case, if another send operation is finally actions:
received, the Printer responds with an "client-error-not-possible"
or "client-error-not-found" depending on whether or not the Job
object is still around when the send operation finally arrives.
2. Assume that the last send operation received was in fact the last
document (as if the "last-document" flag had been set to 'true'),
close the Job object, and proceed to process it (i.e., move the
Job's state to 'pending').
3. Assume that the last send operation received was in fact the last
document, close the Job, but move it to the 'pending-held' and add
the 'submission-interrupted' value to the job's "job-state-reasons"
Isaacson, Powell Expires May 16, 1999 1. Assume that the Job is an invalid job, start the process of
attribute (see section 4.3.8), if supported. This action allows changing the job state to 'aborted', add the 'aborted-by-system'
the user or an operator to determine whether to continue processing value to the job's "job-state-reasons" attribute (see section
the Job by moving it back to the 'pending' state or to cancel the 4.3.8), if supported, and clean up all resources associated with
job. the Job. In this case, if another send operation is finally
received, the Printer responds with an "client-error-not-
possible" or "client-error-not-found" depending on whether or
not the Job object is still around when the send operation
finally arrives.
2. Assume that the last send operation received was in fact the
last document (as if the "last-document" flag had been set to '
true'), close the Job object, and proceed to process it (i.e.,
move the Job's state to 'pending').
3. Assume that the last send operation received was in fact the
last document, close the Job, but move it to the 'pending-held'
and add the 'submission-interrupted' value to the job's "job-
state-reasons" attribute (see section 4.3.8), if supported.
This action allows the user or an operator to determine whether
to continue processing the Job by moving it back to the '
pending' state or to cancel the job.
Each implementation is free to decide the "best" action to take Each implementation is free to decide the "best" action to take
depending on local policy, whether any documents have been added, depending on local policy, whether any documents have been added,
whether the implementation spools jobs or not, and/or any other piece whether the implementation spools jobs or not, and/or any other piece
of information available to it. If the choice is to abort the Job of information available to it. If the choice is to abort the Job
object, it is possible that the Job object may already have been object, it is possible that the Job object may already have been
processed to the point that some media sheet pages have been printed. processed to the point that some media sheet pages have been printed.
3.3.1.1 Send-Document Request 3.3.1.1 Send-Document Request
The following attribute sets are part of the Send-Document Request: The following attribute sets are part of the Send-Document Request:
Group 1: Operation Attributes
Natural Language and Character Set: Group 1: Operation Attributes
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1.
Target: Natural Language and Character Set:
Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX))or The "attributes-charset" and "attributes-natural-language"
(2) the "job-uri" (uri) operation attribute(s) which define the attributes as described in section 3.1.4.1.
target for this operation as described in section 3.1.5.
Requesting User Name: Target:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied Either (1) the "printer-uri" (uri) plus "job-id"
by the client as described in section 8.3. (integer(1:MAX))or (2) the "job-uri" (uri) operation
attribute(s) which define the target for this operation as
described in section 3.1.5.
"document-name" (name(MAX)): Requesting User Name:
The client OPTIONALLY supplies this attribute. The Printer object "requesting-user-name" (name(MAX)) attribute SHOULD be supplied
MUST support this attribute. It contains the client supplied by the client as described in section 8.3.
document name. The document name MAY be different than the Job
name. It might be helpful, but NEED NOT be unique across multiple
documents in the same Job. Typically, the client software
automatically supplies the document name on behalf of the end user
by using a file name or an application generated name. See the
description of the "document-name" operation attribute in the
Print-Job Request (section 3.2.1.1) for more information about this
attribute.
"document-format" (mimeMediaType) : "document-name" (name(MAX)):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
MUST support this attribute. The value of this attribute object MUST support this attribute. It contains the client
identifies the format of the supplied document data. If the client supplied document name. The document name MAY be different than
does not supply this attribute, the Printer object assumes that the the Job name. It might be helpful, but NEED NOT be unique
document data is in the format defined by the Printer object's across multiple documents in the same Job. Typically, the
"document-format-default" attribute. If the client supplies this client software automatically supplies the document name on
attribute, but the value is not supported by the Printer object, behalf of the end user by using a file name or an application
i.e., the value is not one of the values of the Printer object's generated name. See the description of the "document-name"
"document-format-supported" attribute, the Printer object MUST operation attribute in the Print-Job Request (section 3.2.1.1)
for more information about this attribute
Isaacson, Powell Expires May 16, 1999 "document-format" (mimeMediaType):
reject the request and return the 'client-error-document-format- The client OPTIONALLY supplies this attribute. The Printer
not-supported' status code. object MUST support this attribute. The value of this attribute
identifies the format of the supplied document data. If the
client does not supply this attribute, the Printer object
assumes that the document data is in the format defined by the
Printer object's "document-format-default" attribute. If the
client supplies this attribute, but the value is not supported
by the Printer object, i.e., the value is not one of the values
of the Printer object's "document-format-supported" attribute,
the Printer object MUST reject the request and return the '
client-error-document-format-not-supported' status code.
"document-natural-language" (naturalLanguage): "document-natural-language" (naturalLanguage):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute. This attribute specifies the object OPTIONALLY supports this attribute. This attribute
natural language of the document for those document-formats that specifies the natural language of the document for those
require a specification of the natural language in order to image document-formats that require a specification of the natural
the document unambiguously. There are no particular values language in order to image the document unambiguously. There
required for the Printer object to support. are no particular values required for the Printer object to
support.
"compression" (type3 keyword) "compression" (type3 keyword)
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute and the "compression-supported" object OPTIONALLY supports this attribute and the "compression-
attribute (see section 4.4.29). The client supplied "compression" supported" attribute (see section 4.4.29). The client supplied
operation attribute identifies the compression algorithm used on "compression" operation attribute identifies the compression
the document data. If the client omits this attribute, the Printer algorithm used on the document data. If the client omits this
object MUST assume that the data is not compressed. If the client attribute, the Printer object MUST assume that the data is not
supplies the attribute and the Printer object supports the compressed. If the client supplies the attribute and the
attribute, the Printer object MUST use the corresponding Printer object supports the attribute, the Printer object MUST
decompression algorithm on the document data. If the client use the corresponding decompression algorithm on the document
supplies this attribute, but the value is not supported by the data. If the client supplies this attribute, but the value is
Printer object, i.e., the value is not one of the values of the not supported by the Printer object, i.e., the value is not one
Printer object's "compression-supported" attribute, the Printer of the values of the Printer object's "compression-supported"
object MUST copy the attribute and its value to the Unsupported attribute, the Printer object MUST copy the attribute and its
Attributes response group, reject the request, and return the value to the Unsupported Attributes response group, reject the
'client-error-attributes-or-values-not-supported' status code. request, and return the 'client-error-attributes-or-values-not-
supported' status code.
"last-document" (boolean): "last-document" (boolean):
The client MUST supply this attribute. The Printer object MUST The client MUST supply this attribute. The Printer object MUST
support this attribute. It is a boolean flag that is set to 'true' support this attribute. It is a boolean flag that is set to '
if this is the last document for the Job, 'false' otherwise. true' if this is the last document for the Job, 'false'
otherwise.
Group 2: Document Content Group 2: Document Content
The client MUST supply the document data if the "last-document" The client MUST supply the document data if the "last-document"
flag is set to 'false'. However, since a client might not know flag is set to 'false'. However, since a client might not know
that the previous document sent with a Send-Document (or Send-URI) that the previous document sent with a Send-Document (or Send-
operation was the last document (i.e., the "last-document" URI) operation was the last document (i.e., the "last-document"
attribute was set to 'false'), it is legal to send a Send-Document attribute was set to 'false'), it is legal to send a Send-
request with no document data where the "last-document" flag is set Document request with no document data where the "last-document"
to 'true'. Such a request MUST NOT increment the value of the Job flag is set to 'true'. Such a request MUST NOT increment the
object's "number-of-documents" attribute, since no real document value of the Job object's "number-of-documents" attribute, since
was added to the job. no real document was added to the job.
3.3.1.2 Send-Document Response 3.3.1.2 Send-Document Response
The following sets of attributes are part of the Send-Document Response: The following sets of attributes are part of the Send-Document
Response:
Isaacson, Powell Expires May 16, 1999 Group 1: Operation Attributes
Group 1: Operation Attributes
Status Message: Status Message:
In addition to the REQUIRED status code returned in every response, In addition to the REQUIRED status code returned in every
the response OPTIONALLY includes a "status-message" (text) response, the response OPTIONALLY includes a "status-message"
operation attribute as described in sections 14 and 3.1.6. (text) operation attribute as described in sections 14 and
3.1.6.
Natural Language and Character Set: Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language" The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2. attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes Group 2: Unsupported Attributes
This is a set of Operation attributes supplied by the client (in This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or that the request) that are not supported by the Printer object or
conflict with one another (see sections 3.2.1.2 and the that conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [IPP-IIG]). If the Printer object is not Implementer's Guide [ipp-iig]). If the Printer object is not
returning any Unsupported Attributes in the response, the Printer returning any Unsupported Attributes in the response, the
object SHOULD omit Group 2 rather than sending an empty group. Printer object SHOULD omit Group 2 rather than sending an empty
However, a client MUST be able to accept an empty group. group. However, a client MUST be able to accept an empty group.
Group 3: Job Object Attributes Group 3: Job Object Attributes
This is the same set of attributes as described in the Print-Job This is the same set of attributes as described in the Print-Job
response (see section 3.2.1.2). response (see section 3.2.1.2).
3.3.2 Send-URI Operation 3.3.2 Send-URI Operation
This OPTIONAL operation is identical to the Send-Document operation (see This OPTIONAL operation is identical to the Send-Document operation
section 3.3.1) except that a client MUST supply a URI reference (see section 3.3.1) except that a client MUST supply a URI reference
("document-uri" operation attribute) rather than the document data ("document-uri" operation attribute) rather than the document data
itself. If a Printer object supports this operation, clients can use itself. If a Printer object supports this operation, clients can use
both Send-URI or Send-Document operations to add new documents to an both Send-URI or Send-Document operations to add new documents to an
existing multi-document Job object. However, if a client needs to existing multi-document Job object. However, if a client needs to
indicate that the previous Send-URI or Send-Document was the last indicate that the previous Send-URI or Send-Document was the last
document, the client MUST use the Send-Document operation with no document, the client MUST use the Send-Document operation with no
document data and the "last-document" flag set to 'true' (rather than document data and the "last-document" flag set to 'true' (rather than
using a Send-URI operation with no "document-uri" operation attribute). using a Send-URI operation with no "document-uri" operation
attribute).
If a Printer object supports this operation, it MUST also support the If a Printer object supports this operation, it MUST also support the
Print-URI operation (see section 3.2.2). Print-URI operation (see section 3.2.2).
The Printer object MUST validate the syntax and URI scheme of the The Printer object MUST validate the syntax and URI scheme of the
supplied URI before returning a response, just as in the Print-URI supplied URI before returning a response, just as in the Print-URI
operation. operation.
3.3.3 Cancel-Job Operation 3.3.3 Cancel-Job Operation
This REQUIRED operation allows a client to cancel a Print Job from the This REQUIRED operation allows a client to cancel a Print Job from
time the job is created up to the time it is completed, canceled, or the time the job is created up to the time it is completed, canceled,
aborted. Since a Job might already be printing by the time a Cancel-Job or aborted. Since a Job might already be printing by the time a
is received, some media sheet pages might be printed before the job is Cancel-Job is received, some media sheet pages might be printed
actually terminated. before the job is actually terminated.
Isaacson, Powell Expires May 16, 1999
3.3.3.1 Cancel-Job Request 3.3.3.1 Cancel-Job Request
The following groups of attributes are part of the Cancel-Job Request: The following groups of attributes are part of the Cancel-Job
Request:
Group 1: Operation Attributes Group 1: Operation Attributes
Natural Language and Character Set: Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language" The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1. attributes as described in section 3.1.4.1.
Target: Target:
Either (1) the "printer-uri" (uri) plus "job-id" Either (1) the "printer-uri" (uri) plus "job-id"
(integer(1:MAX))or (2) the "job-uri" (uri) operation attribute(s) (integer(1:MAX))or (2) the "job-uri" (uri) operation
which define the target for this operation as described in section attribute(s) which define the target for this operation as
3.1.5. described in section 3.1.5.
Requesting User Name: Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied The "requesting-user-name" (name(MAX)) attribute SHOULD be
by the client as described in section 8.3. supplied by the client as described in section 8.3.
"message" (text(127)): "message" (text(127)):
The client OPTIONALLY supplies this attribute. The Printer object The client OPTIONALLY supplies this attribute. The Printer
OPTIONALLY supports this attribute. It is a message to the object OPTIONALLY supports this attribute. It is a message to
operator. This "message" attribute is not the same as the "job- the operator. This "message" attribute is not the same as the
message-from-operator" attribute. That attribute is used to report "job-message-from-operator" attribute. That attribute is used
a message from the operator to the end user that queries that to report a message from the operator to the end user that
attribute. This "message" operation attribute is used to send a queries that attribute. This "message" operation attribute is
message from the client to the operator along with the operation used to send a message from the client to the operator along
request. It is an implementation decision of how or where to with the operation request. It is an implementation decision of
display this message to the operator (if at all). how or where to display this message to the operator (if at
all).
3.3.3.2 Cancel-Job Response 3.3.3.2 Cancel-Job Response
The following sets of attributes are part of the Cancel-Job Response: The following sets of attributes are part of the Cancel-Job Response:
Group 1: Operation Attributes
Status Message: Group 1: Operation Attributes
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text)
operation attribute as described in sections 14 and 3.1.6.
If the job is already in the 'completed', 'aborted', or 'canceled' Status Message:
state, or the 'process-to-stop-point' value is set in the Job's In addition to the REQUIRED status code returned in every
"job-state-reasons" attribute, the Printer object MUST reject the response, the response OPTIONALLY includes a "status-message"
request and return the 'client-error-not-possible' error status (text) operation attribute as described in sections 14 and
code. 3.1.6.
Natural Language and Character Set: If the job is already in the 'completed', 'aborted', or '
The "attributes-charset" and "attributes-natural-language" canceled' state, or the 'process-to-stop-point' value is set in
attributes as described in section 3.1.4.2. the Job's "job-state-reasons" attribute, the Printer object MUST
reject the request and return the 'client-error-not-possible'
error status code.
Isaacson, Powell Expires May 16, 1999 Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2.
Group 2: Unsupported Attributes Group 2: Unsupported Attributes
This is a set of Operation attributes supplied by the client (in This is a set of Operation attributes supplied by the client (in
the request) that are not supported by the Printer object or that the request) that are not supported by the Printer object or
conflict with one another (see section 3.2.1.2 and the that conflict with one another (see section 3.2.1.2 and the
Implementer's Guide [IPP-IIG]). If the Printer object is not Implementer's Guide [ipp-iig]). If the Printer object is not
returning any Unsupported Attributes in the response, the Printer returning any Unsupported Attributes in the response, the
object SHOULD omit Group 2 rather than sending an empty group. Printer object SHOULD omit Group 2 rather than sending an empty
However, a client MUST be able to accept an empty group. group. However, a client MUST be able to accept an empty group.
Once a successful response has been sent, the implementation guarantees Once a successful response has been sent, the implementation
that the Job will eventually end up in the 'canceled' state. Between the guarantees that the Job will eventually end up in the 'canceled'
time of the Cancel-Job operation is accepted and when the job enters the state. Between the time of the Cancel-Job operation is accepted and
'canceled' job-state (see section 4.3.7), the "job-state-reasons" when the job enters the 'canceled' job-state (see section 4.3.7), the
attribute SHOULD contain the ' processing-to-stop-point ' value which "job-state-reasons" attribute SHOULD contain the 'processing-to-
indicates to later queries that although the Job might still be stop-point' value which indicates to later queries that although the
'processing', it will eventually end up in the 'canceled' state, not the Job might still be 'processing', it will eventually end up in the '
'completed' state. canceled' state, not the 'completed' state.
3.3.4 Get-Job-Attributes Operation 3.3.4 Get-Job-Attributes Operation
This REQUIRED operation allows a client to request the values of This REQUIRED operation allows a client to request the values of
attributes of a Job object and it is almost identical to the Get- attributes of a Job object and it is almost identical to the Get-
Printer-Attributes operation (see section 3.2.5). The only differences Printer-Attributes operation (see section 3.2.5). The only
are that the operation is directed at a Job object rather than a Printer differences are that the operation is directed at a Job object rather
object, there is no "document-format" operation attribute used when than a Printer object, there is no "document-format" operation
querying a Job object, and the returned attribute group is a set of Job attribute used when querying a Job object, and the returned attribute
object attributes rather than a set of Printer object attributes. group is a set of Job object attributes rather than a set of Printer
object attributes.
For Jobs, the possible names of attribute groups are: For Jobs, the possible names of attribute groups are:
- 'job-template': all of the Job Template attributes that apply to a - 'job-template': all of the Job Template attributes that apply to a
Job object (the first column of the table in Section 4.2). Job object (the first column of the table in Section 4.2).
- 'job-description': all of the Job Description attributes specified - 'job-description': all of the Job Description attributes specified
in Section 4.3. in Section 4.3.
- 'all': the special group 'all' that includes all supported - 'all': the special group 'all' that includes all supported
attributes. attributes.
Since a client MAY request specific attributes or named groups, there is Since a client MAY request specific attributes or named groups, there
a potential that there is some overlap. For example, if a client is a potential that there is some overlap. For example, if a client
requests, 'job-name' and 'job-description', the client is actually requests, 'job-name' and 'job-description', the client is actually
requesting the "job-name" attribute once by naming it explicitly, and requesting the "job-name" attribute once by naming it explicitly, and
once by inclusion in the 'job-description' group. In such cases, the once by inclusion in the 'job-description' group. In such cases, the
Printer object NEED NOT return the attribute only once in the response Printer object NEED NOT return the attribute only once in the
even if it is requested multiple times. The client SHOULD NOT request response even if it is requested multiple times. The client SHOULD
the same attribute in multiple ways. NOT request the same attribute in multiple ways.
It is NOT REQUIRED that a Job object support all attributes belonging to It is NOT REQUIRED that a Job object support all attributes belonging
a group (since some attributes are OPTIONAL). However it is REQUIRED to a group (since some attributes are OPTIONAL). However it is
that each Job object support all group names. REQUIRED that each Job object support all group names.
Isaacson, Powell Expires May 16, 1999
3.3.4.1 Get-Job-Attributes Request 3.3.4.1 Get-Job-Attributes Request
The following groups of attributes are part of the Get-Job-Attributes The following groups of attributes are part of the Get-Job-Attributes
Request when the request is directed at a Job object: Request when the request is directed at a Job object:
Group 1: Operation Attributes Group 1: Operation Attributes
Natural Language and Character Set: Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language" The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.1. attributes as described in section 3.1.4.1.
Target: Target:
Either (1) the "printer-uri" (uri) plus "job-id" (integer(1:MAX)) Either (1) the "printer-uri" (uri) plus "job-id"
or (2) the "job-uri" (uri) operation attribute(s) which define the (integer(1:MAX)) or (2) the "job-uri" (uri) operation
target for this operation as described in section 3.1.5. attribute(s) which define the target for this operation as
described in section 3.1.5.
Requesting User Name: Requesting User Name:
The "requesting-user-name" (name(MAX)) attribute SHOULD be supplied The "requesting-user-name" (name(MAX)) attribute SHOULD be
by the client as described in section 8.3. supplied by the client as described in section 8.3.
"requested-attributes" (1setOf keyword) : "requested-attributes" (1setOf keyword) :
The client OPTIONALLY supplies this attribute. The IPP object MUST The client OPTIONALLY supplies this attribute. The IPP object
support this attribute. It is a set of attribute names and/or MUST support this attribute. It is a set of attribute names
attribute group names in whose values the requester is interested. and/or attribute group names in whose values the requester is
If the client omits this attribute, the IPP object MUST respond as interested. If the client omits this attribute, the IPP object
if this attribute had been supplied with a value of 'all'. MUST respond as if this attribute had been supplied with a value
of 'all'.
3.3.4.2 Get-Job-Attributes Response 3.3.4.2 Get-Job-Attributes Response
The Printer object returns the following sets of attributes as part of The Printer object returns the following sets of attributes as part
the Get-Job-Attributes Response: of the Get-Job-Attributes Response:
Group 1: Operation Attributes
Status Message: Group 1: Operation Attributes
In addition to the REQUIRED status code returned in every response,
the response OPTIONALLY includes a "status-message" (text)
operation attribute as described in sections 14 and 3.1.6.
Natural Language and Character Set: Status Message:
The "attributes-charset" and "attributes-natural-language" In addition to the REQUIRED status code returned in every
attributes as described in section 3.1.4.2. The "attributes- response, the response OPTIONALLY includes a "status-message"
natural-language" MAY be the natural language of the Job object, (text) operation attribute as described in sections 14 and
rather than the one requested. 3.1.6.
Group 2: Unsupported Attributes Natural Language and Character Set:
The "attributes-charset" and "attributes-natural-language"
attributes as described in section 3.1.4.2. The "attributes-
natural-language" MAY be the natural language of the Job object,
rather than the one requested.
This is a set of Operation attributes supplied by the client (in Group 2: Unsupported Attributes
the request) that are not supported by the Printer object or that
conflict with one another (see sections 3.2.1.2 and the
Implementer's Guide [IPP-IIG]). The response NEED NOT contain the
"requested-attributes" operation attribute with any supplied values
(attribute keywords) that were requested by the client but are not
Isaacson, Powell Expires May 16, 1999 This is a set of Operation attributes supplied by the client (in
supported by the IPP object. If the Printer object is not the request) that are not supported by the Printer object or
returning any Unsupported Attributes in the response, the Printer that conflict with one another (see sections 3.2.1.2 and the
object SHOULD omit Group 2 rather than sending an empty group. Implementer's Guide [ipp-iig]). The response NEED NOT contain
However, a client MUST be able to accept an empty group. the "requested-attributes" operation attribute with any supplied
values (attribute keywords) that were requested by the client
but are not supported by the IPP object. If the Printer object
is not returning any Unsupported Attributes in the response, the
Printer object SHOULD omit Group 2 rather than sending an empty
group. However, a client MUST be able to accept an empty group.
Group 3: Job Object Attributes Group 3: Job Object Attributes
This is the set of requested attributes and their current values. This is the set of requested attributes and their current
The IPP object ignores (does not respond with) any requested values. The IPP object ignores (does not respond with) any
attribute or value which is not supported or which is restricted by requested attribute or value which is not supported or which is
the security policy in force, including whether the requesting user restricted by the security policy in force, including whether
is the user that submitted the job (job originating user) or not the requesting user is the user that submitted the job (job
(see section 8). However, the IPP object MUST respond with the originating user) or not (see section 8). However, the IPP
'unknown' value for any supported attribute (including all REQUIRED object MUST respond with the 'unknown' value for any supported
attributes) for which the IPP object does not know the value, attribute (including all RED butes) for which the IPP object
unless it would violate the security policy. See the description does not know the value, s it would violate the security policy.
of the "out-of-band" values in the beginning of Section 4.1. See the description e "out-of-band" values in the beginning of
Section 4.1.
4. Object Attributes 4. Object Attributes
This section describes the attributes with their corresponding attribute This section describes the attributes with their corresponding
syntaxes and values that are part of the IPP model. The sections below attribute syntaxes and values that are part of the IPP model. The
show the objects and their associated attributes which are included sections below show the objects and their associated attributes which
within the scope of this protocol. Many of these attributes are derived are included within the scope of this protocol. Many of these
from other relevant specifications: attributes are derived from other relevant specifications:
- Document Printing Application (DPA) [ISO10175] - Document Printing Application (DPA) [ISO10175]
- RFC 1759 Printer MIB [RFC1759] - RFC 1759 Printer MIB [RFC1759]
Each attribute is uniquely identified in this document using a "keyword" Each attribute is uniquely identified in this document using a
(see section 13.2.1) which is the name of the attribute. The keyword is "keyword" (see section 12.2.1) which is the name of the attribute.
included in the section header describing that attribute. The keyword is included in the section header describing that
attribute.
Note: Not only are keywords used to identify attributes, but one of the Note: Not only are keywords used to identify attributes, but one of
attribute syntaxes described below is "keyword" so that some attributes the attribute syntaxes described below is "keyword" so that some
have keyword values. Therefore, these attributes are defined as having attributes have keyword values. Therefore, these attributes are
an attribute syntax that is a set of keywords. defined as having an attribute syntax that is a set of keywords.
4.1 Attribute Syntaxes 4.1 Attribute Syntaxes
This section defines the basic attribute syntax types that all clients This section defines the basic attribute syntax types that all clients
and IPP objects MUST be able to accept in responses and accept in and IPP objects MUST be able to accept in responses and accept in
requests, respectively. Each attribute description in sections 3 and 4 requests, respectively. Each attribute description in sections 3 and
includes the name of attribute syntax(es) in the heading (in 4 includes the name of attribute syntax(es) in the heading (in
parentheses). A conforming implementation of an attribute MUST include parentheses). A conforming implementation of an attribute MUST
the semantics of the attribute syntax(es) so identified. Section 6.3 include the semantics of the attribute syntax(es) so identified.
describes how the protocol can be extended with new attribute syntaxes. Section 6.3 describes how the protocol can be extended with new
attribute syntaxes.
The attribute syntaxes are specified in the following sub-sections, The attribute syntaxes are specified in the following sub-sections,
where the sub-section heading is the keyword name of the attribute where the sub-section heading is the keyword name of the attribute
syntax inside the single quotes. In operation requests and responses syntax inside the single quotes. In operation requests and responses
each attribute value MUST be represented as one of the attribute each attribute value MUST be represented as one of the attribute
syntaxes specified in the sub-section heading for the attribute. In
addition, the value of an attribute in a response (but not in a
request) MAY be one of the "out-of-band" values. Standard
"out-of-band" values are:
Isaacson, Powell Expires May 16, 1999 'unknown': The attribute is supported by the IPP object, but the
syntaxes specified in the sub-section heading for the attribute. In value is unknown to the IPP object for some reason.
addition, the value of an attribute in a response (but not in a request) 'unsupported': The attribute is unsupported by the IPP object. This
MAY be one of the "out-of-band" values. Standard "out-of-band" values value MUST be returned only as the value of an attribute in the
are: Unsupported Attributes Group.
'no-value': The attribute is supported by the Printer object, but
the system administrator has not yet configured a value.
'unknown': The attribute is supported by the IPP object, but the The Encoding and Transport specification [RFC2565] defines mechanisms
value is unknown to the IPP object for some reason. for passing "out-of-band" values. All attributes in a request MUST
'unsupported': The attribute is unsupported by the IPP object. This have one or more values as defined in Sections 4.2 to 4.4. Thus
value MUST be returned only as the value of an attribute in the clients MUST NOT supply attributes with "out-of-band" values. All
Unsupported Attributes Group. attribute in a response MUST have one or more values as defined in
'no-value': The attribute is supported by the Printer object, but the Sections 4.2 to 4.4 or a single "out-of-band" value.
system administrator has not yet configured a value.
The Encoding and Transport specification [IPP-PRO] defines mechanisms Most attributes are defined to have a single attribute syntax.
for passing "out-of-band" values. All attributes in a request MUST have However, a few attributes (e.g., "job-sheet", "media", "job-hold-
one or more values as defined in Sections 4.2 to 4.4. Thus clients MUST until") are defined to have several attribute syntaxes, depending on
NOT supply attributes with "out-of-band" values. All attribute in a the value. These multiple attribute syntaxes are separated by the
response MUST have one or more values as defined in Sections 4.2 to 4.4 "|" character in the sub-section heading to indicate the choice.
or a single "out-of-band" value. Since each value MUST be tagged as to its attribute syntax in the
Most attributes are defined to have a single attribute syntax. However, protocol, a single-valued attribute instance may have any one of its
a few attributes (e.g., "job-sheet", "media", "job-hold-until") are attribute syntaxes and a multi-valued attribute instance may have a
defined to have several attribute syntaxes, depending on the value. mixture of its defined attribute syntaxes.
These multiple attribute syntaxes are separated by the "|" character in
the sub-section heading to indicate the choice. Since each value MUST
be tagged as to its attribute syntax in the protocol, a single-valued
attribute instance may have any one of its attribute syntaxes and a
multi-valued attribute instance may have a mixture of its defined
attribute syntaxes.
4.1.1 'text' 4.1.1 'text'
A text attribute is an attribute whose value is a sequence of zero or A text attribute is an attribute whose value is a sequence of zero or
more characters encoded in a maximum of 1023 ('MAX') octets. MAX is the more characters encoded in a maximum of 1023 ('MAX') octets. MAX is
maximum length for each value of any text attribute. However, if an the maximum length for each value of any text attribute. However, if
attribute will always contain values whose maximum length is much less an attribute will always contain values whose maximum length is much
than MAX, the definition of that attribute will include a qualifier that less than MAX, the definition of that attribute will include a
defines the maximum length for values of that attribute. For example: qualifier that defines the maximum length for values of that
the "printer-location" attribute is specified as "printer-location attribute. For example: the "printer-location" attribute is
(text(127))". In this case, text values for "printer-location" MUST NOT specified as "printer-location (text(127))". In this case, text
exceed 127 octets; if supplied with a longer text string via some values for "printer-location" MUST NOT exceed 127 octets; if supplied
external interface (other than the protocol), implementations are free with a longer text string via some external interface (other than the
to truncate to this shorter length limitation. protocol), implementations are free to truncate to this shorter
length limitation.
In this specification, all text attributes are defined using the 'text'
syntax. However, 'text' is used only for brevity; the formal
interpretation of 'text' is: 'textWithoutLanguage | textWithLanguage'.
That is, for any attribute defined in this specification using the
'text' attribute syntax, all IPP objects and clients MUST support both
the 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes.
However, in actual usage and protocol execution, objects and clients
Isaacson, Powell Expires May 16, 1999 In this specification, all text attributes are defined using the '
accept and return only one of the two syntax per attribute. The syntax text' syntax. However, 'text' is used only for brevity; the formal
'text' never appears "on-the-wire". interpretation of 'text' is: 'textWithoutLanguage |
textWithLanguage'. That is, for any attribute defined in this
specification using the 'text' attribute syntax, all IPP objects and
clients MUST support both the 'textWithoutLanguage' and '
textWithLanguage' attribute syntaxes. However, in actual usage and
protocol execution, objects and clients accept and return only one of
the two syntax per attribute. The syntax 'text' never appears "on-
the-wire".
Both 'textWithoutLanguage' and 'textWithLanguage' are needed to support Both 'textWithoutLanguage' and 'textWithLanguage' are needed to
the real world needs of interoperability between sites and systems that support the real world needs of interoperability between sites and
use different natural languages as the basis for human communication. systems that use different natural languages as the basis for human
Generally, one natural language applies to all text attributes in a communication. Generally, one natural language applies to all text
given request or response. The language is indicated by the "attributes- attributes in a given request or response. The language is indicated
natural-language" operation attribute defined in section 3.1.4 or by the "attributes-natural-language" operation attribute defined in
"attributes-natural-language" job attribute defined in section 4.3.24, section 3.1.4 or "attributes-natural-language" job attribute defined
and there is no need to identify the natural language for each text in section 4.3.24, and there is no need to identify the natural
string on a value-by-value basis. In these cases, the attribute syntax language for each text string on a value-by-value basis. In these
'textWithoutLanguage' is used for text attributes. In other cases, the cases, the attribute syntax 'textWithoutLanguage' is used for text
client needs to supply or the Printer object needs to return a text attributes. In other cases, the client needs to supply or the
value in a natural language that is different from the rest of the text Printer object needs to return a text value in a natural language
values in the request or response. In these cases, the client or that is different from the rest of the text values in the request or
Printer object uses the attribute syntax 'textWithLanguage' for text response. In these cases, the client or Printer object uses the
attributes (this is the Natural Language Override mechanism described in attribute syntax 'textWithLanguage' for text attributes (this is the
section 3.1.4). Natural Language Override mechanism described in section 3.1.4).
The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes are The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes
described in more detail in the following sections. are described in more detail in the following sections.
4.1.1.1 'textWithoutLanguage' 4.1.1.1 'textWithoutLanguage'
The 'textWithoutLanguage' syntax indicates a value that is sequence of The 'textWithoutLanguage' syntax indicates a value that is sequence
zero or more characters. Text strings are encoded using the rules of of zero or more characters. Text strings are encoded using the rules
some charset. The Printer object MUST support the UTF-8 charset of some charset. The Printer object MUST support the UTF-8 charset
[RFC2044] and MAY support additional charsets to represent 'text' [RFC2279] and MAY support additional charsets to represent 'text'
values, provided that the charsets are registered with IANA [IANA-CS]. values, provided that the charsets are registered with IANA [IANA-
See Section 4.1.7 for the specification of the 'charset' attribute CS]. See Section 4.1.7 for the specification of the 'charset'
syntax, including restricted semantics and examples of charsets. attribute syntax, including restricted semantics and examples of
charsets.
4.1.1.2 'textWithLanguage' 4.1.1.2 'textWithLanguage'
The 'textWithLanguage' attribute syntax is a compound attribute syntax The 'textWithLanguage' attribute syntax is a compound attribute
consisting of two parts: a 'textWithoutLanguage' part plus an additional syntax consisting of two parts: a 'textWithoutLanguage' part plus an
'naturalLanguage' (see section 4.1.8) part that overrides the natural additional 'naturalLanguage' (see section 4.1.8) part that overrides
language in force. The 'naturalLanguage' part explicitly identifies the the natural language in force. The 'naturalLanguage' part explicitly
natural language that applies to the text part of that value and that identifies the natural language that applies to the text part of that
value alone. For any give text attribute, the 'textWithoutLanguage' value and that value alone. For any give text attribute, the '
part is limited to the maximum length defined for that attribute, but textWithoutLanguage' part is limited to the maximum length defined
the 'naturalLanguage' part is always limited to 63 octets. Using the for that attribute, but the 'naturalLanguage' part is always limited
'textWithLanguage' attribute syntax rather than the normal to 63 octets. Using the 'textWithLanguage' attribute syntax rather
'textWithoutLanguage' syntax is the so-called Natural Language Override than the normal 'textWithoutLanguage' syntax is the so-called Natural
mechanism and MUST be supported by all IPP objects and clients. Language Override mechanism and MUST be supported by all IPP objects
and clients.
If the attribute is multi-valued (1setOf text), then the If the attribute is multi-valued (1setOf text), then the '
'textWithLanguage' attribute syntax MUST be used to explicitly specify textWithLanguage' attribute syntax MUST be used to explicitly specify
each attribute value whose natural language needs to be overridden. each attribute value whose natural language needs to be overridden.
Other values in a multi-valued 'text' attribute in a request or a Other values in a multi-valued 'text' attribute in a request or a
response revert to the natural language of the operation attribute. response revert to the natural language of the operation attribute.
Isaacson, Powell Expires May 16, 1999 In a create request, the Printer object MUST accept and store with
In a create request, the Printer object MUST accept and store with the the Job object any natural language in the "attributes-natural-
Job object any natural language in the "attributes-natural-language" language" operation attribute, whether the Printer object supports
operation attribute, whether the Printer object supports that natural that natural language or not. Furthermore, the Printer object MUST
language or not. Furthermore, the Printer object MUST accept and store accept and store any 'textWithLanguage' attribute value, whether the
any 'textWithLanguage' attribute value, whether the Printer object Printer object supports that natural language or not. These
supports that natural language or not. These requirements are requirements are independent of the value of the "ipp-attribute-
independent of the value of the "ipp-attribute-fidelity" operation fidelity" operation attribute that the client MAY supply.
attribute that the client MAY supply.
Example: If the client supplies the "attributes-natural-language" Example: If the client supplies the "attributes-natural-language"
operation attribute with the value: 'en' indicating English, but the operation attribute with the value: 'en' indicating English, but the
value of the "job-name" attribute is in French, the client MUST use the value of the "job-name" attribute is in French, the client MUST use
'textWithLanguage' attribute syntax with the following two values: the 'textWithLanguage' attribute syntax with the following two
values:
'fr': Natural Language Override indicating French 'fr': Natural Language Override indicating French
'Rapport Mensuel': the job name in French 'Rapport Mensuel': the job name in French
See the Encoding and Transport document [IPP-PRO] for a detailed example See the Encoding and Transport document [RFC2565] for a detailed
of the 'textWithLanguage' attribute syntax. example of the 'textWithLanguage' attribute syntax.
4.1.2 'name' 4.1.2 'name'
This syntax type is used for user-friendly strings, such as a Printer This syntax type is used for user-friendly strings, such as a Printer
name, that, for humans, are more meaningful than identifiers. Names are name, that, for humans, are more meaningful than identifiers. Names
never translated from one natural language to another. The 'name' are never translated from one natural language to another. The '
attribute syntax is essentially the same as 'text', including the name' attribute syntax is essentially the same as 'text', including
REQUIRED support of UTF-8 except that the sequence of characters is the REQUIRED support of UTF-8 except that the sequence of characters
limited so that its encoded form MUST NOT exceed 255 (MAX) octets. is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
Also like 'text', 'name' is really an abbreviated notation for either Also like 'text', 'name' is really an abbreviated notation for either
'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP objects 'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP
and clients MUST support both the 'nameWithoutLanguage' and objects and clients MUST support both the 'nameWithoutLanguage' and '
'nameWithLanguage' attribute syntaxes. However, in actual usage and nameWithLanguage' attribute syntaxes. However, in actual usage and
protocol execution, objects and clients accept and return only one of protocol execution, objects and clients accept and return only one of
the two syntax per attribute. The syntax 'name' never appears "on-the- the two syntax per attribute. The syntax 'name' never appears "on-
wire". the-wire".
Note: Only the 'text' and 'name' attribute syntaxes permit the Natural Note: Only the 'text' and 'name' attribute syntaxes permit the
Language Override mechanism. Natural Language Override mechanism.
Some attributes are defined as 'type3 keyword | name'. These attributes Some attributes are defined as 'type3 keyword | name'. These
support values that are either type3 keywords or names. This dual- attributes support values that are either type3 keywords or names.
syntax mechanism enables a site administrator to extend these attributes This dual-syntax mechanism enables a site administrator to extend
to legally include values that are locally defined by the site these attributes to legally include values that are locally defined
administrator. Such names are not registered with IANA. by the site administrator. Such names are not registered with IANA.
4.1.2.1 'nameWithoutLanguage' 4.1.2.1 'nameWithoutLanguage'
The nameWithoutLanguage' syntax indicates a value that is sequence of The 'nameWithoutLanguage' syntax indicates a value that is sequence
zero or more characters so that its encoded form does not exceed MAX of zero or more characters so that its encoded form does not exceed
octets. MAX octets.
Isaacson, Powell Expires May 16, 1999
4.1.2.2 'nameWithLanguage' 4.1.2.2 'nameWithLanguage'
The 'nameWithLanguage' attribute syntax is a compound attribute syntax The 'nameWithLanguage' attribute syntax is a compound attribute
consisting of two parts: a 'nameWithoutLanguage' part plus an additional syntax consisting of two parts: a 'nameWithoutLanguage' part plus an
'naturalLanguage' (see section 4.1.8) part that overrides the natural additional 'naturalLanguage' (see section 4.1.8) part that overrides
language in force. The 'naturalLanguage' part explicitly identifies the the natural language in force. The 'naturalLanguage' part explicitly
natural language that applies to that name value and that name value identifies the natural language that applies to that name value and
alone. that name value alone.
The 'nameWithLanguage' attribute syntax behaves the same as the The 'nameWithLanguage' attribute syntax behaves the same as the '
'textWithLanguage' syntax. If a name is in a language that is different textWithLanguage' syntax. If a name is in a language that is
than the rest of the object or operation, then this 'nameWithLanguage' different than the rest of the object or operation, then this '
syntax is used rather than the generic 'nameWithoutLanguage' syntax. nameWithLanguage' syntax is used rather than the generic '
nameWithoutLanguage' syntax.
Example: If the client supplies the "attributes-natural-language" Example: If the client supplies the "attributes-natural-language"
operation attribute with the value: 'en' indicating English, but the operation attribute with the value: 'en' indicating English, but the
"printer-name" attribute is in German, the client MUST use the "printer-name" attribute is in German, the client MUST use the '
'nameWithLanguage' attribute syntax as follows: nameWithLanguage' attribute syntax as follows:
'de': Natural Language Override indicating German 'de': Natural Language Override indicating German
'Farbdrucker': the Printer name in German 'Farbdrucker': the Printer name in German
4.1.2.3 Matching 'name' attribute values 4.1.2.3 Matching 'name' attribute values
For purposes of matching two 'name' attribute values for equality, such For purposes of matching two 'name' attribute values for equality,
as in job validation (where a client-supplied value for attribute "xxx" such as in job validation (where a client-supplied value for
is checked to see if the value is among the values of the Printer attribute "xxx" is checked to see if the value is among the values of
object's corresponding "xxx-supported" attribute), the following match the Printer object's corresponding "xxx-supported" attribute), the
rules apply: following match rules apply:
1. 'keyword' values never match 'name' values. 1. 'keyword' values never match 'name' values.
2. 'name' (nameWithoutLanguage and nameWithLanguage) values match 2. 'name' (nameWithoutLanguage and nameWithLanguage) values
if (1) the name parts match and (2) the Associated Natural-Language match if (1) the name parts match and (2) the Associated
parts (see section 3.1.4.1) match. The matching rules are: Natural-Language parts (see section 3.1.4.1) match. The
matching rules are:
a. the name parts match if the two names are identical a. the name parts match if the two names are identical
character by character, except it is RECOMMENDED that case be character by character, except it is RECOMMENDED that case
ignored. For example: 'Ajax-letter-head-white' MUST match be ignored. For example: 'Ajax-letter-head-white' MUST
'Ajax-letter-head-white' and SHOULD match 'ajax-letter-head- match 'Ajax-letter-head-white' and SHOULD match 'ajax-
white' and 'AJAX-LETTER-HEAD-WHITE'. letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'.
b. the Associated Natural-Language parts match if the shorter b. the Associated Natural-Language parts match if the
of the two meets the syntactic requirements of RFC 1766 shorter of the two meets the syntactic requirements of RFC
[RFC1766] and matches byte for byte with the longer. For 1766 [RFC1766] and matches byte for byte with the longer.
example, 'en' matches 'en', 'en-us' and 'en-gb', but matches For example, 'en' matches 'en', 'en-us' and 'en-gb', but
neither 'fr' nor 'e'. matches neither 'fr' nor 'e'.
4.1.3 'keyword' 4.1.3 'keyword'
The 'keyword' attribute syntax is a sequence of characters, length: 1 to The 'keyword' attribute syntax is a sequence of characters, length: 1
255, containing only the US-ASCII [ASCII] encoded values for lowercase to 255, containing only the US-ASCII [ASCII] encoded values for
letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot ("."), and lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot
("."), and underscore ("_"). The first character MUST be a lowercase
Isaacson, Powell Expires May 16, 1999 letter. Furthermore, keywords MUST be in U.S. English.
underscore ("_"). The first character MUST be a lowercase letter.
Furthermore, keywords MUST be in U.S. English.
This syntax type is used for enumerating semantic identifiers of This syntax type is used for enumerating semantic identifiers of
entities in the abstract protocol, i.e., entities identified in this entities in the abstract protocol, i.e., entities identified in this
document. Keywords are used as attribute names or values of attributes. document. Keywords are used as attribute names or values of
Unlike 'text' and 'name' attribute values, 'keyword' values MUST NOT use attributes. Unlike 'text' and 'name' attribute values, 'keyword'
the Natural Language Override mechanism, since they MUST always be US- values MUST NOT use the Natural Language Override mechanism, since
ASCII and U.S. English. they MUST always be US-ASCII and U.S. English.
Keywords are for use in the protocol. A user interface will likely Keywords are for use in the protocol. A user interface will likely
provide a mapping between protocol keywords and displayable user- provide a mapping between protocol keywords and displayable user-
friendly words and phrases which are localized to the natural language friendly words and phrases which are localized to the natural
of the user. While the keywords specified in this document MAY be language of the user. While the keywords specified in this document
displayed to users whose natural language is U.S. English, they MAY be MAY be displayed to users whose natural language is U.S. English,
mapped to other U.S. English words for U.S. English users, since the they MAY be mapped to other U.S. English words for U.S. English
user interface is outside the scope of this document. users, since the user interface is outside the scope of this
document.
In the definition for each attribute of this syntax type, the full set In the definition for each attribute of this syntax type, the full
of defined keyword values for that attribute are listed. set of defined keyword values for that attribute are listed.
When a keyword is used to represent an attribute (its name), it MUST be When a keyword is used to represent an attribute (its name), it MUST
unique within the full scope of all IPP objects and attributes. When a be unique within the full scope of all IPP objects and attributes.
keyword is used to represent a value of an attribute, it MUST be unique When a keyword is used to represent a value of an attribute, it MUST
just within the scope of that attribute. That is, the same keyword MUST be unique just within the scope of that attribute. That is, the same
NOT be used for two different values within the same attribute to mean keyword MUST NOT be used for two different values within the same
two different semantic ideas. However, the same keyword MAY be used attribute to mean two different semantic ideas. However, the same
across two or more attributes, representing different semantic ideas for keyword MAY be used across two or more attributes, representing
each attribute. Section 6.1 describes how the protocol can be extended different semantic ideas for each attribute. Section 6.1 describes
with new keyword values. Examples of attribute name keywords: how the protocol can be extended with new keyword values. Examples
of attribute name keywords:
"job-name" "job-name"
"attributes-charset" "attributes-charset"
Note: This document uses "type1", "type2", and "type3" prefixes to the Note: This document uses "type1", "type2", and "type3" prefixes to
"keyword" basic syntax to indicate different levels of review for the "keyword" basic syntax to indicate different levels of review for
extensions (see section 6.1). extensions (see section 6.1).
4.1.4 'enum' 4.1.4 'enum'
The 'enum' attribute syntax is an enumerated integer value that is in The 'enum' attribute syntax is an enumerated integer value that is in
the range from 1 to 2**31 - 1 (MAX). Each value has an associated the range from 1 to 2**31 - 1 (MAX). Each value has an associated '
'keyword' name. In the definition for each attribute of this syntax keyword' name. In the definition for each attribute of this syntax
type, the full set of possible values for that attribute are listed. type, the full set of possible values for that attribute are listed.
This syntax type is used for attributes for which there are enum values This syntax type is used for attributes for which there are enum
assigned by other standards, such as SNMP MIBs. A number of attribute values assigned by other standards, such as SNMP MIBs. A number of
enum values in this specification are also used for corresponding attribute enum values in this specification are also used for
attributes in other standards [RFC1759]. This syntax type is not used corresponding attributes in other standards [RFC1759]. This syntax
for attributes to which the system administrator may assign values. type is not used for attributes to which the system administrator may
Section 6.1 describes how the protocol can be extended with new enum assign values. Section 6.1 describes how the protocol can be
values. extended with new enum values.
Isaacson, Powell Expires May 16, 1999 Enum values are for use in the protocol. A user interface will
Enum values are for use in the protocol. A user interface will provide provide a mapping between protocol enum values and displayable user-
a mapping between protocol enum values and displayable user-friendly friendly words and phrases which are localized to the natural
words and phrases which are localized to the natural language of the language of the user. While the enum symbols specified in this
user. While the enum symbols specified in this document MAY be document MAY be displayed to users whose natural language is U.S.
displayed to users whose natural language is U.S. English, they MAY be English, they MAY be mapped to other U.S. English words for U.S.
mapped to other U.S. English words for U.S. English users, since the English users, since the user interface is outside the scope of this
user interface is outside the scope of this document. document.
Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP "out- Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP
of-band" value 'unknown'. See the description of the "out-of-band" "out-of-band" value 'unknown'. See the description of the "out-of-
values at the beginning of Section 4.1. Therefore, attributes of type band" values at the beginning of Section 4.1. Therefore, attributes
'enum' start at '3'. of type 'enum' start at '3'.
Note: This document uses "type1", "type2", and "type3" prefixes to the Note: This document uses "type1", "type2", and "type3" prefixes to
"enum" basic syntax to indicate different levels of review for the "enum" basic syntax to indicate different levels of review for
extensions (see section 6.1). extensions (see section 6.1).
4.1.5 'uri' 4.1.5 'uri'
The 'uri' attribute syntax is any valid Uniform Resource Identifier or The 'uri' attribute syntax is any valid Uniform Resource Identifier
URI [RFC2396]. Most often, URIs are simply Uniform Resource Locators or or URI [RFC2396]. Most often, URIs are simply Uniform Resource
URLs. The maximum length of URIs used as values of IPP attributes is Locators or URLs. The maximum length of URIs used as values of IPP
1023 octets. Although most other IPP attribute syntax types allow for attributes is 1023 octets. Although most other IPP attribute syntax
only lower-cased values, this attribute syntax type conforms to the types allow for only lower-cased values, this attribute syntax type
case-sensitive and case-insensitive rules specified in [RFC2396]. conforms to the case-sensitive and case-insensitive rules specified
in [RFC2396].
4.1.6 'uriScheme' 4.1.6 'uriScheme'
The 'uriScheme' attribute syntax is a sequence of characters The 'uriScheme' attribute syntax is a sequence of characters
representing a URI scheme according to RFC 2396 [RFC2396]. Though RFC representing a URI scheme according to RFC 2396 [RFC2396]. Though
2396 requires that the values be case-insensitive, IPP requires all RFC 2396 requires that the values be case-insensitive, IPP requires
lower case values in IPP attributes to simplify comparing by IPP clients all lower case values in IPP attributes to simplify comparing by IPP
and Printer objects. Standard values for this syntax type are the clients and Printer objects. Standard values for this syntax type
following keywords: are the following keywords:
'http': for HTTP schemed URIs (e.g., "http:.") 'http': for HTTP schemed URIs (e.g., "http:...")
'https': for use with HTTPS schemed URIs (e.g., "https:...") (not on 'https': for use with HTTPS schemed URIs (e.g., "https:...")
IETF standards track) (not on IETF standards track)
'ftp': for FTP schemed URIs (e.g., "ftp:...") 'ftp': for FTP schemed URIs (e.g., "ftp:...")
'mailto': for SMTP schemed URIs (e.g., "mailto:...") 'mailto': for SMTP schemed URIs (e.g., "mailto:...")
'file': for file schemed URIs (e.g., "file:...") 'file': for file schemed URIs (e.g., "file:...")
A Printer object MAY support any URI 'scheme' that has been registered A Printer object MAY support any URI 'scheme' that has been
with IANA [IANA-MT]. The maximum length of URI 'scheme' values used to registered with IANA [IANA-MT]. The maximum length of URI 'scheme'
represent IPP attribute values is 63 octets. values used to represent IPP attribute values is 63 octets.
4.1.7 'charset' 4.1.7 'charset'
The 'charset' attribute syntax is a standard identifier for a charset. The 'charset' attribute syntax is a standard identifier for a
A charset is a coded character set and encoding scheme. Charsets are charset. A charset is a coded character set and encoding scheme.
used for labeling certain document contents and 'text' and 'name' Charsets are used for labeling certain document contents and 'text'
attribute values. The syntax and semantics of this attribute syntax are and 'name' attribute values. The syntax and semantics of this
attribute syntax are specified in RFC 2046 [RFC2046] and contained in
the IANA character-set Registry [IANA-CS] according to the IANA
procedures [RFC2278]. Though RFC 2046 requires that the values be
case-insensitive US-ASCII, IPP requires all lower case values in IPP
attributes to simplify comparing by IPP clients and Printer objects.
When a character-set in the IANA registry has more than one name
(alias), the name labeled as "(preferred MIME name)", if present,
MUST be used.
Isaacson, Powell Expires May 16, 1999 The maximum length of 'charset' values used to represent IPP
specified in RFC 2046 [RFC2046] and contained in the IANA character-set attribute values is 63 octets.
Registry [IANA-CS] according to the IANA procedures [RFC2278]. Though
RFC 2046 requires that the values be case-insensitive US-ASCII, IPP
requires all lower case values in IPP attributes to simplify comparing
by IPP clients and Printer objects. When a character-set in the IANA
registry has more than one name (alias), the name labeled as "(preferred
MIME name)", if present, MUST be used.
The maximum length of 'charset' values used to represent IPP attribute Some examples are:
values is 63 octets.
Some examples are: 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set
(UCS) represented as the UTF-8 [RFC2279] transfer encoding
scheme in which US-ASCII is a subset charset.
'us-ascii': 7-bit American Standard Code for Information
Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard
defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the
control characters from conformant usage in MIME and IPP.
'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet
Nr 1 [ISO8859-1]. That standard defines a coded character set
that is used by Latin languages in the Western Hemisphere and
Western Europe. US-ASCII is a subset charset.
'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set 'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded
(UCS) represented as the UTF-8 [RFC2279] transfer encoding scheme Character Set (UCS) represented as two octets (UCS-2), with the
in which US-ASCII is a subset charset. high order octet of each pair coming first (so-called Big Endian
'us-ascii': 7-bit American Standard Code for Information Interchange integer).
(ASCII), ANSI X3.4-1986 [ASCII]. That standard defines US-ASCII,
but RFC 2045 [RFC2045] eliminates most of the control characters
from conformant usage in MIME and IPP.
'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet Nr
1 [ISO8859-1]. That standard defines a coded character set that is
used by Latin languages in the Western Hemisphere and Western
Europe. US-ASCII is a subset charset.
'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded
Character Set (UCS) represented as two octets (UCS-2), with the
high order octet of each pair coming first (so-called Big Endian
integer).
Some attribute descriptions MAY place additional requirements on charset Some attribute descriptions MAY place additional requirements on
values that may be used, such as REQUIRED values that MUST be supported charset values that may be used, such as REQUIRED values that MUST be
or additional restrictions, such as requiring that the charset have US- supported or additional restrictions, such as requiring that the
ASCII as a subset charset. charset have US-ASCII as a subset charset.
4.1.8 'naturalLanguage' 4.1.8 'naturalLanguage'
The 'naturalLanguage' attribute syntax is a standard identifier for a The 'naturalLanguage' attribute syntax is a standard identifier for a
natural language and optionally a country. The values for this syntax natural language and optionally a country. The values for this
type are defined by RFC 1766 [RFC1766]. Though RFC 1766 requires that syntax type are defined by RFC 1766 [RFC1766]. Though RFC 1766
the values be case-insensitive US-ASCII, IPP requires all lower case to requires that the values be case-insensitive US-ASCII, IPP requires
simplify comparing by IPP clients and Printer objects. Examples all lower case to simplify comparing by IPP clients and Printer
include: objects. Examples include:
'en': for English 'en': for English
'en-us': for US English 'en-us': for US English
'fr': for French 'fr': for French
'de': for German 'de': for German
The maximum length of 'naturalLanguage' values used to represent IPP The maximum length of 'naturalLanguage' values used to represent IPP
attribute values is 63 octets. attribute values is 63 octets.
Isaacson, Powell Expires May 16, 1999
4.1.9 'mimeMediaType' 4.1.9 'mimeMediaType'
The 'mimeMediaType' attribute syntax is the Internet Media Type The 'mimeMediaType' attribute syntax is the Internet Media Type
(sometimes called MIME type) as defined by RFC 2046 [RFC2046] and (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and
registered according to the procedures of RFC 2048 [RFC2048] for registered according to the procedures of RFC 2048 [RFC2048] for
identifying a document format. The value MAY include a charset identifying a document format. The value MAY include a charset
parameter, depending on the specification of the Media Type in the IANA parameter, depending on the specification of the Media Type in the
Registry [IANA-MT]. Although most other IPP syntax types allow for only IANA Registry [IANA-MT]. Although most other IPP syntax types allow
lower-cased values, this syntax type allows for mixed-case values which for only lower-cased values, this syntax type allows for mixed-case
are case-insensitive. values which are case-insensitive.
Examples are:
'text/html': An HTML document Examples are:
'text/plain': A plain text document in US-ASCII (RFC 2046 indicates
that in the absence of the charset parameter MUST mean US-ASCII
rather than simply unspecified) [RFC2046].
'text/plain; charset=US-ASCII': A plain text document in US-ASCII
[52, 56].
'text/plain; charset=ISO-8859-1': A plain text document in ISO 8859-
1 (Latin 1) [ISO8859-1].
'text/plain; charset=utf-8': A plain text document in ISO 10646
represented as UTF-8 [RFC2044]
'text/plain, charset=iso-10646-ucs-2': A plain text document in ISO
10646 represented in two octets (UCS-2) [ISO10646-1]
'application/postscript': A PostScript document [RFC2046]
'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape
sequence embedded in the document data)
'application/octet-stream': Auto-sense - see below
One special type is 'application/octet-stream'. If the Printer object 'text/html': An HTML document
supports this value, the Printer object MUST be capable of auto-sensing 'text/plain': A plain text document in US-ASCII (RFC 2046 indicates
the format of the document data. If the Printer object's default value that in the absence of the charset parameter MUST mean US-ASCII
attribute "document-format-default" is set to 'application/octet- rather than simply unspecified) [RFC2046].
stream', the Printer object not only supports auto-sensing of the 'text/plain; charset=US-ASCII': A plain text document in US-ASCII
document format, but will depend on the result of applying its auto- [52, 56].
sensing when the client does not supply the "document-format" attribute. 'text/plain; charset=ISO-8859-1': A plain text document in ISO
If the client supplies a document format value, the Printer MUST rely on 8859-1 (Latin 1) [ISO8859-1].
the supplied attribute, rather than trust its auto-sensing algorithm.
To summarize:
1. If the client does not supply a document format value, the Printer 'text/plain; charset=utf-8': A plain text document in ISO 10646
MUST rely on its default value setting (which may be represented as UTF-8 [RFC2279]
'application/octet-stream' indicating an auto-sensing mechanism). 'text/plain, charset=iso-10646-ucs-2': A plain text document in
2. If the client supplies a value other than 'application/octet- ISO 10646 represented in two octets (UCS-2) [ISO10646-1]
stream', the client is supplying valid information about the format 'application/postscript': A PostScript document [RFC2046]
of the document data and the Printer object MUST trust the client 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape
supplied value more than the outcome of applying an automatic sequence embedded in the document data)
format detection mechanism. For example, the client may be 'application/octet-stream': Auto-sense - see below
requesting the printing of a PostScript file as a 'text/plain'
document. The Printer object MUST print a text representation of
the PostScript commands rather than interpret the stream of
PostScript commands and print the result.
Isaacson, Powell Expires May 16, 1999 One special type is 'application/octet-stream'. If the Printer
object supports this value, the Printer object MUST be capable of
auto-sensing the format of the document data. If the Printer
object's default value attribute "document-format-default" is set to
'application/octet-stream', the Printer object not only supports
auto-sensing of the document format, but will depend on the result of
applying its auto-sensing when the client does not supply the
"document-format" attribute. If the client supplies a document
format value, the Printer MUST rely on the supplied attribute, rather
than trust its auto-sensing algorithm. To summarize:
3. If the client supplies a value of 'application/octet-stream', the 1. If the client does not supply a document format value, the
client is indicating that the Printer object MUST use its auto- Printer MUST rely on its default value setting (which may be '
sensing mechanism on the client supplied document data whether application/octet-stream' indicating an auto-sensing mechanism).
auto-sensing is the Printer object's default or not. 2. If the client supplies a value other than 'application/octet-
stream', the client is supplying valid information about the
format of the document data and the Printer object MUST trust
the client supplied value more than the outcome of applying an
automatic format detection mechanism. For example, the client
may be requesting the printing of a PostScript file as a '
text/plain' document. The Printer object MUST print a text
representation of the PostScript commands rather than interpret
the stream of PostScript commands and print the result.
3. If the client supplies a value of 'application/octet-stream',
the client is indicating that the Printer object MUST use its
auto-sensing mechanism on the client supplied document data
whether auto-sensing is the Printer object's default or not.
Note: Since the auto-sensing algorithm is probabilistic, if the client Note: Since the auto-sensing algorithm is probabilistic, if the
requests both auto-sensing ("document-format" set to 'application/octet- client requests both auto-sensing ("document-format" set to '
stream') and true fidelity ("ipp-attribute-fidelity" set to 'true'), the application/octet-stream') and true fidelity ("ipp-attribute-
Printer object might not be able to guarantee exactly what the end user fidelity" set to 'true'), the Printer object might not be able to
intended (the auto-sensing algorithm might mistake one document format guarantee exactly what the end user intended (the auto-sensing
for another ), but it is able to guarantee that its auto-sensing algorithm might mistake one document format for another ), but it is
mechanism be used. able to guarantee that its auto-sensing mechanism be used.
The maximum length of a 'mimeMediaType' value to represent IPP attribute The maximum length of a 'mimeMediaType' value to represent IPP
values is 255 octets. attribute values is 255 octets.
4.1.10 'octetString' 4.1.10 'octetString'
The 'octetString' attribute syntax is a sequence of octets encoded in a The 'octetString' attribute syntax is a sequence of octets encoded in
maximum of 1023 octets which is indicated in sub-section headers using a maximum of 1023 octets which is indicated in sub-section headers
the notation: octetString(MAX). This syntax type is used for opaque using the notation: octetString(MAX). This syntax type is used for
data. opaque data.
4.1.11 'boolean' 4.1.11 'boolean'
The 'boolean' attribute syntax has only two values: 'true' and 'false'. The 'boolean' attribute syntax has only two values: 'true' and '
false'.
4.1.12 'integer' 4.1.12 'integer'
The 'integer' attribute syntax is an integer value that is in the range The 'integer' attribute syntax is an integer value that is in the
from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual attribute may range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual
specify the range constraint explicitly in sub-section headers if the attribute may specify the range constraint explicitly in sub-section
range is different from the full range of possible integer values. For headers if the range is different from the full range of possible
example: job-priority (integer(1:100)) for the "job-priority" integer values. For example: job-priority (integer(1:100)) for the
attribute. However, the enforcement of that additional constraint is up "job-priority" attribute. However, the enforcement of that
to the IPP objects, not the protocol. additional constraint is up to the IPP objects, not the protocol.
4.1.13 'rangeOfInteger' 4.1.13 'rangeOfInteger'
The 'rangeOfInteger' attribute syntax is an ordered pair of integers The 'rangeOfInteger' attribute syntax is an ordered pair of integers
that defines an inclusive range of integer values. The first integer that defines an inclusive range of integer values. The first integer
specifies the lower bound and the second specifies the upper bound. If specifies the lower bound and the second specifies the upper bound.
a range constraint is specified in the header description for an If a range constraint is specified in the header description for an
attribute in this document whose attribute syntax is 'rangeOfInteger' attribute in this document whose attribute syntax is 'rangeOfInteger'
(i.e., 'X:Y' indicating X as a minimum value and Y as a maximum value), (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum
then the constraint applies to both integers. value), then the constraint applies to both integers.
4.1.14 'dateTime' 4.1.14 'dateTime'
The 'dateTime' attribute syntax is a standard, fixed length, 11 octet The 'dateTime' attribute syntax is a standard, fixed length, 11 octet
representation of the "DateAndTime" syntax as defined in RFC 1903 representation of the "DateAndTime" syntax as defined in RFC 2579
[RFC2579]. RFC 2579 also identifies an 8 octet representation of a
Isaacson, Powell Expires May 16, 1999 "DateAndTime" value, but IPP objects MUST use the 11 octet
[RFC1903]. RFC 1903 also identifies an 8 octet representation of a representation. A user interface will provide a mapping between
"DateAndTime" value, but IPP objects MUST use the 11 octet protocol dateTime values and displayable user-friendly words or
representation. A user interface will provide a mapping between presentation values and phrases which are localized to the natural
protocol dateTime values and displayable user-friendly words or language and date format of the user.
presentation values and phrases which are localized to the natural
language and date format of the user.
4.1.15 'resolution' 4.1.15 'resolution'
The 'resolution' attribute syntax specifies a two-dimensional resolution The 'resolution' attribute syntax specifies a two-dimensional
in the indicated units. It consists of 3 values: a cross feed direction resolution in the indicated units. It consists of 3 values: a cross
resolution (positive integer value), a feed direction resolution feed direction resolution (positive integer value), a feed direction
(positive integer value), and a units value. The semantics of these resolution (positive integer value), and a units value. The
three components are taken from the Printer MIB [RFC1759] suggested semantics of these three components are taken from the Printer MIB
values. That is, the cross feed direction component resolution [RFC1759] suggested values. That is, the cross feed direction
component is the same as the prtMarkerAddressabilityXFeedDir object in component resolution component is the same as the
the Printer MIB, the feed direction component resolution component is prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed
the same as the prtMarkerAddressabilityFeedDir in the Printer MIB, and direction component resolution component is the same as the
the units component is the same as the prtMarkerAddressabilityUnit prtMarkerAddressabilityFeedDir in the Printer MIB, and the units
object in the Printer MIB (namely, '3' indicates dots per inch and '4' component is the same as the prtMarkerAddressabilityUnit object in
indicates dots per centimeter). All three values MUST be present even the Printer MIB (namely, '3' indicates dots per inch and '4'
if the first two values are the same. Example: '300', '600', '3' indicates dots per centimeter). All three values MUST be present
indicates a 300 dpi cross-feed direction resolution, a 600 dpi feed even if the first two values are the same. Example: '300', '600', '
direction resolution, since a '3' indicates dots per inch (dpi). 3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi
feed direction resolution, since a '3' indicates dots per inch (dpi).
4.1.16 '1setOf X' 4.1.16 '1setOf X'
The '1setOf X' attribute syntax is 1 or more values of attribute syntax The '1setOf X' attribute syntax is 1 or more values of attribute
type X. This syntax type is used for multi-valued attributes. The syntax type X. This syntax type is used for multi-valued attributes.
syntax type is called '1setOf' rather than just 'setOf' as a reminder The syntax type is called '1setOf' rather than just 'setOf' as a
that the set of values MUST NOT be empty (i.e., a set of size 0). Sets reminder that the set of values MUST NOT be empty (i.e., a set of
are normally unordered. However each attribute description of this type size 0). Sets are normally unordered. However each attribute
may specify that the values MUST be in a certain order for that description of this type may specify that the values MUST be in a
attribute. certain order for that attribute.
4.2 Job Template Attributes 4.2 Job Template Attributes
Job Template attributes describe job processing behavior. Support for Job Template attributes describe job processing behavior. Support
Job Template attributes by a Printer object is OPTIONAL (see section for Job Template attributes by a Printer object is OPTIONAL (see
13.2.3 for a description of support for OPTIONAL attributes). Also, section 13.2.3 for a description of support for OPTIONAL attributes).
clients OPTIONALLY supply Job Template attributes in create requests. Also, clients OPTIONALLY supply Job Template attributes in create
requests.
Job Template attributes conform to the following rules. For each Job
Template attribute called "xxx":
1. If the Printer object supports "xxx" then it MUST support both a
"xxx-default" attribute (unless there is a "No" in the table below)
and a "xxx-supported" attribute. If the Printer object doesn't
support "xxx", then it MUST support neither an "xxx-default"
attribute nor an "xxx-supported" attribute, and it MUST treat an
attribute "xxx" supplied by a client as unsupported. An attribute
"xxx" may be supported for some document formats and not supported
Isaacson, Powell Expires May 16, 1999
for other document formats. For example, it is expected that a