]>
Commit | Line | Data |
---|---|---|
ef416fc2 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group R. deBry | |
8 | Request for Comments: 2566 Utah Valley State College | |
9 | Category: Experimental T. Hastings | |
10 | Xerox Corporation | |
11 | R. Herriot | |
12 | Xerox Corporation | |
13 | S. Isaacson | |
14 | Novell, Inc. | |
15 | P. Powell | |
16 | Astart Technologies | |
17 | April 1999 | |
18 | ||
19 | ||
20 | Internet Printing Protocol/1.0: Model and Semantics | |
21 | ||
22 | Status of this Memo | |
23 | ||
24 | This memo defines an Experimental Protocol for the Internet | |
25 | community. It does not specify an Internet standard of any kind. | |
26 | Discussion and suggestions for improvement are requested. | |
27 | Distribution of this memo is unlimited. | |
28 | ||
29 | Copyright Notice | |
30 | ||
31 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
32 | ||
33 | IESG Note | |
34 | ||
35 | This document defines an Experimental protocol for the Internet | |
36 | community. The IESG expects that a revised version of this protocol | |
37 | will be published as Proposed Standard protocol. The Proposed | |
38 | Standard, when published, is expected to change from the protocol | |
39 | defined in this memo. In particular, it is expected that the | |
40 | standards-track version of the protocol will incorporate strong | |
41 | authentication and privacy features, and that an "ipp:" URL type will | |
42 | be defined which supports those security measures. Other changes to | |
43 | the protocol are also possible. Implementors are warned that future | |
44 | versions of this protocol may not interoperate with the version of | |
45 | IPP defined in this document, or if they do interoperate, that some | |
46 | protocol features may not be available. | |
47 | ||
48 | The IESG encourages experimentation with this protocol, especially in | |
49 | combination with Transport Layer Security (TLS) [RFC 2246], to help | |
50 | determine how TLS may effectively be used as a security layer for | |
51 | IPP. | |
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | deBry, et al. Experimental [Page 1] | |
59 | \f | |
60 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
61 | ||
62 | ||
63 | Abstract | |
64 | ||
65 | This document is one of a set of documents, which together describe | |
66 | all aspects of a new Internet Printing Protocol (IPP). IPP is an | |
67 | application level protocol that can be used for distributed printing | |
68 | using Internet tools and technologies. This document describes a | |
69 | simplified model consisting of abstract objects, their attributes, | |
70 | and their operations that is independent of encoding and transport. | |
71 | The model consists of a Printer and a Job object. A Job optionally | |
72 | supports multiple documents. IPP 1.0 semantics allow end-users and | |
73 | operators to query printer capabilities, submit print jobs, inquire | |
74 | about the status of print jobs and printers, and cancel print jobs. | |
75 | This document also addresses security, internationalization, and | |
76 | directory issues. | |
77 | ||
78 | The full set of IPP documents includes: | |
79 | ||
80 | Design Goals for an Internet Printing Protocol [RFC2567] | |
81 | Rationale for the Structure and Model and Protocol for the Internet | |
82 | Printing Protocol [RFC2568] | |
83 | Internet Printing Protocol/1.0: Model and Semantics (this document) | |
84 | Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] | |
85 | Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] | |
86 | Mapping between LPD and IPP Protocols [RFC2569] | |
87 | ||
88 | The "Design Goals for an Internet Printing Protocol" document takes a | |
89 | broad look at distributed printing functionality, and it enumerates | |
90 | real-life scenarios that help to clarify the features that need to be | |
91 | included in a printing protocol for the Internet. It identifies | |
92 | requirements for three types of users: end users, operators, and | |
93 | administrators. It calls out a subset of end user requirements that | |
94 | are satisfied in IPP/1.0. Operator and administrator requirements | |
95 | are out of scope for version 1.0. | |
96 | ||
97 | The "Rationale for the Structure and Model and Protocol for the | |
98 | Internet Printing Protocol" document describes IPP from a high level | |
99 | view, defines a roadmap for the various documents that form the suite | |
100 | of IPP specifications, and gives background and rationale for the | |
101 | IETF working group's major decisions. | |
102 | ||
103 | The "Internet Printing Protocol/1.0: Encoding and Transport" document | |
104 | is a formal mapping of the abstract operations and attributes defined | |
105 | in the model document onto HTTP/1.1. It defines the encoding rules | |
106 | for a new Internet media type called "application/ipp". | |
107 | ||
108 | The "Internet Printing Protocol/1.0: Implementer's Guide" document | |
109 | gives insight and advice to implementers of IPP clients and IPP | |
110 | objects. It is intended to help them understand IPP/1.0 and some of | |
111 | ||
112 | ||
113 | ||
114 | deBry, et al. Experimental [Page 2] | |
115 | \f | |
116 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
117 | ||
118 | ||
119 | the considerations that may assist them in the design of their client | |
120 | and/or IPP object implementations. For example, a typical order of | |
121 | processing requests is given, including error checking. Motivation | |
122 | for some of the specification decisions is also included. | |
123 | ||
124 | The "Mapping between LPD and IPP Protocols" document gives some | |
125 | advice to implementers of gateways between IPP and LPD (Line Printer | |
126 | Daemon) implementations. | |
127 | ||
128 | Table of Contents | |
129 | ||
130 | 1. Introduction 8 | |
131 | 1.1 Simplified Printing Model 9 | |
132 | 2. IPP Objects 11 | |
133 | 2.1 Printer Object 12 | |
134 | 2.2 Job Object 14 | |
135 | 2.3 Object Relationships 14 | |
136 | 2.4 Object Identity 15 | |
137 | 3. IPP Operations 18 | |
138 | 3.1 Common Semantics 19 | |
139 | 3.1.1 Required Parameters 19 | |
140 | 3.1.2 Operation IDs and Request IDs 20 | |
141 | 3.1.3 Attributes 20 | |
142 | 3.1.4 Character Set and Natural Language Operation Attributes 22 | |
143 | 3.1.4.1 Request Operation Attributes 22 | |
144 | 3.1.4.2 Response Operation Attributes 26 | |
145 | 3.1.5 Operation Targets 28 | |
146 | 3.1.6 Operation Status Codes and Messages 29 | |
147 | 3.1.7 Versions 30 | |
148 | 3.1.8 Job Creation Operations 32 | |
149 | 3.2 Printer Operations 34 | |
150 | 3.2.1 Print-Job Operation 34 | |
151 | 3.2.1.1 Print-Job Request 34 | |
152 | 3.2.1.2 Print-Job Response 38 | |
153 | 3.2.2 Print-URI Operation 41 | |
154 | 3.2.3 Validate-Job Operation 42 | |
155 | 3.2.4 Create-Job Operation 42 | |
156 | 3.2.5 Get-Printer-Attributes Operation 43 | |
157 | 3.2.5.1 Get-Printer-Attributes Request 44 | |
158 | 3.2.5.2 Get-Printer-Attributes Response 46 | |
159 | 3.2.6 Get-Jobs Operation 47 | |
160 | 3.2.6.1 Get-Jobs Request 47 | |
161 | 3.2.6.2 Get-Jobs Response 49 | |
162 | 3.3 Job Operations 50 | |
163 | 3.3.1 Send-Document Operation 50 | |
164 | 3.3.1.1 Send-Document Request 51 | |
165 | 3.3.1.2 Send-Document Response 53 | |
166 | 3.3.2 Send-URI Operation 54 | |
167 | ||
168 | ||
169 | ||
170 | deBry, et al. Experimental [Page 3] | |
171 | \f | |
172 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
173 | ||
174 | ||
175 | 3.3.3 Cancel-Job Operation 54 | |
176 | 3.3.3.1 Cancel-Job Request 54 | |
177 | 3.3.3.2 Cancel-Job Response 55 | |
178 | 3.3.4 Get-Job-Attributes Operation 56 | |
179 | 3.3.4.1 Get-Job-Attributes Request 57 | |
180 | 3.3.4.2 Get-Job-Attributes Response 57 | |
181 | 4. Object Attributes 58 | |
182 | 4.1 Attribute Syntaxes 59 | |
183 | 4.1.1 'text' 60 | |
184 | 4.1.1.1 'textWithoutLanguage' 61 | |
185 | 4.1.1.2 'textWithLanguage' 61 | |
186 | 4.1.2 'name' 62 | |
187 | 4.1.2.1 'nameWithoutLanguage' 62 | |
188 | 4.1.2.2 'nameWithLanguage' 63 | |
189 | 4.1.2.3 Matching 'name' attribute values 63 | |
190 | 4.1.3 'keyword' 64 | |
191 | 4.1.4 'enum' 65 | |
192 | 4.1.5 'uri' 65 | |
193 | 4.1.6 'uriScheme' 65 | |
194 | 4.1.7 'charset' 66 | |
195 | 4.1.8 'naturalLanguage' 67 | |
196 | 4.1.9 'mimeMediaType' 67 | |
197 | 4.1.10 'octetString' 69 | |
198 | 4.1.11 'boolean' 69 | |
199 | 4.1.12 'integer' 69 | |
200 | 4.1.13 'rangeOfInteger' 69 | |
201 | 4.1.14 'dateTime' 69 | |
202 | 4.1.15 'resolution' 69 | |
203 | 4.1.16 '1setOf X' 70 | |
204 | 4.2 Job Template Attributes 70 | |
205 | 4.2.1 job-priority (integer(1:100)) 74 | |
206 | 4.2.2 job-hold-until (type3 keyword | name (MAX)) 75 | |
207 | 4.2.3 job-sheets (type3 keyword | name(MAX)) 75 | |
208 | 4.2.4 multiple-document-handling (type2 keyword) 76 | |
209 | 4.2.5 copies (integer(1:MAX)) 77 | |
210 | 4.2.6 finishings (1setOf type2 enum) 78 | |
211 | 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) 79 | |
212 | 4.2.8 sides (type2 keyword) 80 | |
213 | 4.2.9 number-up (integer(1:MAX)) 80 | |
214 | 4.2.10 orientation-requested (type2 enum) 81 | |
215 | 4.2.11 media (type3 keyword | name(MAX)) 82 | |
216 | 4.2.12 printer-resolution (resolution) 83 | |
217 | 4.2.13 print-quality (type2 enum) 83 | |
218 | 4.3 Job Description Attributes 84 | |
219 | 4.3.1 job-uri (uri) 85 | |
220 | 4.3.2 job-id (integer(1:MAX)) 85 | |
221 | 4.3.3 job-printer-uri (uri) 86 | |
222 | 4.3.4 job-more-info (uri) 86 | |
223 | ||
224 | ||
225 | ||
226 | deBry, et al. Experimental [Page 4] | |
227 | \f | |
228 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
229 | ||
230 | ||
231 | 4.3.5 job-name (name(MAX)) 86 | |
232 | 4.3.6 job-originating-user-name (name(MAX)) 86 | |
233 | 4.3.7 job-state (type1 enum) 87 | |
234 | 4.3.8 job-state-reasons (1setOf type2 keyword) 90 | |
235 | 4.3.9 job-state-message (text(MAX)) 92 | |
236 | 4.3.10 number-of-documents (integer(0:MAX)) 93 | |
237 | 4.3.11 output-device-assigned (name(127)) 93 | |
238 | 4.3.12 time-at-creation (integer(0:MAX)) 93 | |
239 | 4.3.13 time-at-processing (integer(0:MAX)) 93 | |
240 | 4.3.14 time-at-completed (integer(0:MAX)) 94 | |
241 | 4.3.15 number-of-intervening-jobs (integer(0:MAX)) 94 | |
242 | 4.3.16 job-message-from-operator (text(127)) 94 | |
243 | 4.3.17 job-k-octets (integer(0:MAX)) 94 | |
244 | 4.3.18 job-impressions (integer(0:MAX)) 95 | |
245 | 4.3.19 job-media-sheets (integer(0:MAX)) 95 | |
246 | 4.3.20 job-k-octets-processed (integer(0:MAX)) 96 | |
247 | 4.3.21 job-impressions-completed (integer(0:MAX)) 96 | |
248 | 4.3.22 job-media-sheets-completed (integer(0:MAX)) 96 | |
249 | 4.3.23 attributes-charset (charset) 97 | |
250 | 4.3.24 attributes-natural-language (naturalLanguage) 97 | |
251 | 4.4 Printer Description Attributes 97 | |
252 | 4.4.1 printer-uri-supported (1setOf uri) 99 | |
253 | 4.4.2 uri-security-supported (1setOf type2 keyword) 100 | |
254 | 4.4.3 printer-name (name(127)) 101 | |
255 | 4.4.4 printer-location (text(127)) 101 | |
256 | 4.4.5 printer-info (text(127)) 101 | |
257 | 4.4.6 printer-more-info (uri) 101 | |
258 | 4.4.7 printer-driver-installer (uri) 102 | |
259 | 4.4.8 printer-make-and-model (text(127)) 102 | |
260 | 4.4.9 printer-more-info-manufacturer (uri) 102 | |
261 | 4.4.10 printer-state (type1 enum) 102 | |
262 | 4.4.11 printer-state-reasons (1setOf type2 keyword) 103 | |
263 | 4.4.12 printer-state-message (text(MAX)) 106 | |
264 | 4.4.13 operations-supported (1setOf type2 enum) 106 | |
265 | 4.4.14 charset-configured (charset) 107 | |
266 | 4.4.15 charset-supported (1setOf charset) 107 | |
267 | 4.4.16 natural-language-configured (naturalLanguage) 107 | |
268 | 4.4.17 generated-natural-language-supported(1setOf naturalLanguage108 | |
269 | 4.4.18 document-format-default (mimeMediaType) 108 | |
270 | 4.4.19 document-format-supported (1setOf mimeMediaType) 108 | |
271 | 4.4.20 printer-is-accepting-jobs (boolean) 109 | |
272 | 4.4.21 queued-job-count (integer(0:MAX)) 109 | |
273 | 4.4.22 printer-message-from-operator (text(127)) 109 | |
274 | 4.4.23 color-supported (boolean) 109 | |
275 | 4.4.24 reference-uri-schemes-supported (1setOf uriScheme) 109 | |
276 | 4.4.25 pdl-override-supported (type2 keyword) 110 | |
277 | 4.4.26 printer-up-time (integer(1:MAX)) 110 | |
278 | 4.4.27 printer-current-time (dateTime) 111 | |
279 | ||
280 | ||
281 | ||
282 | deBry, et al. Experimental [Page 5] | |
283 | \f | |
284 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
285 | ||
286 | ||
287 | 4.4.28 multiple-operation-time-out (integer(1:MAX)) 111 | |
288 | 4.4.29 compression-supported (1setOf type3 keyword) 111 | |
289 | 4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) 112 | |
290 | 4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) 112 | |
291 | 4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) 112 | |
292 | 5. Conformance 112 | |
293 | 5.1 Client Conformance Requirements 112 | |
294 | 5.2 IPP Object Conformance Requirements 113 | |
295 | 5.2.1 Objects 113 | |
296 | 5.2.2 Operations 113 | |
297 | 5.2.3 IPP Object Attributes 114 | |
298 | 5.2.4 Extensions 114 | |
299 | 5.2.5 Attribute Syntaxes 115 | |
300 | 5.3 Charset and Natural Language Requirements 115 | |
301 | 5.4 Security Conformance Requirements 115 | |
302 | 6. IANA Considerations (registered and private extensions) 116 | |
303 | 6.1 Typed 'keyword' and 'enum' Extensions 116 | |
304 | 6.2 Attribute Extensibility 119 | |
305 | 6.3 Attribute Syntax Extensibility 119 | |
306 | 6.4 Operation Extensibility 120 | |
307 | 6.5 Attribute Groups 120 | |
308 | 6.6 Status Code Extensibility 120 | |
309 | 6.7 Registration of MIME types/sub-types for document-formats 121 | |
310 | 6.8 Registration of charsets for use in 'charset' attribute values121 | |
311 | 7. Internationalization Considerations 121 | |
312 | 8. Security Considerations 125 | |
313 | 8.1 Security Scenarios 126 | |
314 | 8.1.1 Client and Server in the Same Security Domain 126 | |
315 | 8.1.2 Client and Server in Different Security Domains 126 | |
316 | 8.1.3 Print by Reference 127 | |
317 | 8.2 URIs for SSL3 and non-SSL3 Access 127 | |
318 | 8.3 The "requesting-user-name" (name(MAX)) Operation Attribute 127 | |
319 | 8.4 Restricted Queries 129 | |
320 | 8.5 Queries on jobs submitted using non-IPP protocols 129 | |
321 | 8.6 IPP Security Application Profile for SSL3 130 | |
322 | 9. References 131 | |
323 | 10. Authors' Addresses 134 | |
324 | 11. Formats for IPP Registration Proposals 136 | |
325 | 11.1 Type2 keyword attribute values registration 136 | |
326 | 11.2 Type3 keyword attribute values registration 137 | |
327 | 11.3 Type2 enum attribute values registration 137 | |
328 | 11.4 Type3 enum attribute values registration 137 | |
329 | 11.5 Attribute registration 138 | |
330 | 11.6 Attribute Syntax registration 138 | |
331 | 11.7 Operation registration 139 | |
332 | 11.8 Attribute Group registration 139 | |
333 | 11.9 Status code registration 139 | |
334 | 12.APPENDIX A: Terminology 141 | |
335 | ||
336 | ||
337 | ||
338 | deBry, et al. Experimental [Page 6] | |
339 | \f | |
340 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
341 | ||
342 | ||
343 | 12.1 Conformance Terminology 141 | |
344 | 12.1.1 NEED NOT 141 | |
345 | 12.2 Model Terminology 141 | |
346 | 12.2.1 Keyword 141 | |
347 | 12.2.2 Attributes 141 | |
348 | 12.2.2.1 Attribute Name 141 | |
349 | 12.2.2.2 Attribute Group Name 142 | |
350 | 12.2.2.3 Attribute Value 142 | |
351 | 12.2.2.4 Attribute Syntax 142 | |
352 | 12.2.3 Supports 142 | |
353 | 12.2.4 print-stream page 144 | |
354 | 12.2.5 impression 144 | |
355 | 13.APPENDIX B: Status Codes and Suggested Status Code Messages 145 | |
356 | 13.1 Status Codes 146 | |
357 | 13.1.1 Informational 146 | |
358 | 13.1.2 Successful Status Codes 146 | |
359 | 13.1.2.1 successful-ok (0x0000) 146 | |
360 | 13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) 146 | |
361 | 13.1.2.3 successful-ok-conflicting-attributes (0x0002) 147 | |
362 | 13.1.3 Redirection Status Codes 147 | |
363 | 13.1.4 Client Error Status Codes 147 | |
364 | 13.1.4.1 client-error-bad-request (0x0400) 147 | |
365 | 13.1.4.2 client-error-forbidden (0x0401) 147 | |
366 | 13.1.4.3 client-error-not-authenticated (0x0402) 148 | |
367 | 13.1.4.4 client-error-not-authorized (0x0403) 148 | |
368 | 13.1.4.5 client-error-not-possible (0x0404) 148 | |
369 | 13.1.4.6 client-error-timeout (0x0405) 148 | |
370 | 13.1.4.7 client-error-not-found (0x0406) 149 | |
371 | 13.1.4.8 client-error-gone (0x0407) 149 | |
372 | 13.1.4.9 client-error-request-entity-too-large (0x0408) 149 | |
373 | 13.1.4.10client-error-request-value-too-long (0x0409) 150 | |
374 | 13.1.4.11client-error-document-format-not-supported (0x040A) 150 | |
375 | 13.1.4.12client-error-attributes-or-values-not-supported (0x040B) 150 | |
376 | 13.1.4.13client-error-uri-scheme-not-supported (0x040C) 151 | |
377 | 13.1.4.14client-error-charset-not-supported (0x040D) 151 | |
378 | 13.1.4.15client-error-conflicting-attributes (0x040E) 151 | |
379 | 13.1.5 Server Error Status Codes 151 | |
380 | 13.1.5.1 server-error-internal-error (0x0500) 151 | |
381 | 13.1.5.2 server-error-operation-not-supported (0x0501) 152 | |
382 | 13.1.5.3 server-error-service-unavailable (0x0502) 152 | |
383 | 13.1.5.4 server-error-version-not-supported (0x0503) 152 | |
384 | 13.1.5.5 server-error-device-error (0x0504) 152 | |
385 | 13.1.5.6 server-error-temporary-error (0x0505) 153 | |
386 | 13.1.5.7 server-error-not-accepting-jobs (0x0506) 153 | |
387 | 13.1.5.8 server-error-busy (0x0507) 153 | |
388 | 13.1.5.9 server-error-job-canceled (0x0508) 153 | |
389 | 13.2 Status Codes for IPP Operations 153 | |
390 | 14.APPENDIX C: "media" keyword values 155 | |
391 | ||
392 | ||
393 | ||
394 | deBry, et al. Experimental [Page 7] | |
395 | \f | |
396 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
397 | ||
398 | ||
399 | 15.APPENDIX D: Processing IPP Attributes 160 | |
400 | 15.1 Fidelity 160 | |
401 | 15.2 Page Description Language (PDL) Override 161 | |
402 | 15.3 Using Job Template Attributes During Document Processing. 163 | |
403 | 16.APPENDIX E: Generic Directory Schema 166 | |
404 | 17.APPENDIX F: Change History for the Model and Semantics document 168 | |
405 | 18.FULL COPYRIGHT STATEMENT 173 | |
406 | ||
407 | 1. Introduction | |
408 | ||
409 | The Internet Printing Protocol (IPP) is an application level protocol | |
410 | that can be used for distributed printing using Internet tools and | |
411 | technologies. IPP version 1.0 (IPP/1.0) focuses only on end user | |
412 | functionality. This document is just one of a suite of documents | |
413 | that fully define IPP. The full set of IPP documents includes: | |
414 | ||
415 | Design Goals for an Internet Printing Protocol [RFC2567] | |
416 | Rationale for the Structure and Model and Protocol for the Internet | |
417 | Printing Protocol [RFC2568] | |
418 | Internet Printing Protocol/1.0: Model and Semantics (this document) | |
419 | Internet Printing Protocol/1.0: Encoding and Transport [RFC2565] | |
420 | Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig] | |
421 | Mapping between LPD and IPP Protocols [RFC2569] | |
422 | ||
423 | Anyone reading these documents for the first time is strongly | |
424 | encouraged to read the IPP documents in the above order. | |
425 | ||
426 | This document is laid out as follows: | |
427 | ||
428 | - The rest of Section 1 is an introduction to the IPP simplified | |
429 | model for distributed printing. | |
430 | - Section 2 introduces the object types covered in the model with | |
431 | their basic behaviors, attributes, and interactions. | |
432 | - Section 3 defines the operations included in IPP/1.0. IPP | |
433 | operations are synchronous, therefore, for each operation, there | |
434 | is a both request and a response. | |
435 | - Section 4 defines the attributes (and their syntaxes) that are | |
436 | used in the model. | |
437 | - Sections 5 - 6 summarizes the implementation conformance | |
438 | requirements for objects that support the protocol and IANA | |
439 | considerations, respectively. | |
440 | - Sections 7 - 11 cover the Internationalization and Security | |
441 | considerations as well as References, Author contact information, | |
442 | and Formats for Registration Proposals. | |
443 | - Sections 12 - 14 are appendices that cover Terminology, Status | |
444 | Codes and Messages, and "media" keyword values. | |
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
450 | deBry, et al. Experimental [Page 8] | |
451 | \f | |
452 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
453 | ||
454 | ||
455 | Note: This document uses terms such as "attributes", | |
456 | "keywords", and "support". These terms have special | |
457 | meaning and are defined in the model terminology section | |
458 | 12.2. Capitalized terms, such as MUST, MUST NOT, REQUIRED, | |
459 | SHOULD, SHOULD NOT, MAY, NEED NOT, and OPTIONAL, have | |
460 | special meaning relating to conformance. These terms are | |
461 | defined in section 12.1 on conformance terminology, most of | |
462 | which is taken from RFC 2119 [RFC2119]. | |
463 | ||
464 | - Section 15 is an appendix that helps to clarify the effects of | |
465 | interactions between related attributes and their values. | |
466 | - Section 16 is an appendix that enumerates the subset of Printer | |
467 | attributes that form a generic directory schema. These | |
468 | attributes are useful when registering a Printer so that a | |
469 | client can find the Printer not just by name, but by filtered | |
470 | searches as well. | |
471 | - Section 17 is an appendix that provides a Change History | |
472 | summarizing the clarification and changes that might affect an | |
473 | implementation since the June 30, 1998 draft. | |
474 | ||
475 | 1.1 Simplified Printing Model | |
476 | ||
477 | In order to achieve its goal of realizing a workable printing | |
478 | protocol for the Internet, the Internet Printing Protocol (IPP) is | |
479 | based on a simplified printing model that abstracts the many | |
480 | components of real world printing solutions. The Internet is a | |
481 | distributed computing environment where requesters of print services | |
482 | (clients, applications, printer drivers, etc.) cooperate and interact | |
483 | with print service providers. This model and semantics document | |
484 | describes a simple, abstract model for IPP even though the underlying | |
485 | configurations may be complex "n-tier" client/server systems. An | |
486 | important simplifying step in the IPP model is to expose only the key | |
487 | objects and interfaces required for printing. The model described in | |
488 | this model document does not include features, interfaces, and | |
489 | relationships that are beyond the scope of the first version of IPP | |
490 | (IPP/1.0). IPP/1.0 incorporates many of the relevant ideas and | |
491 | lessons learned from other specification and development efforts | |
492 | [HTPP] [ISO10175] [LDPA] [P1387.4] [PSIS] [RFC1179] [SWP]. IPP is | |
493 | heavily influenced by the printing model introduced in the Document | |
494 | Printing Application (DPA) [ISO10175] standard. Although DPA | |
495 | specifies both end user and administrative features, IPP version 1.0 | |
496 | (IPP/1.0) focuses only on end user functionality. | |
497 | ||
498 | The IPP/1.0 model encapsulates the important components of | |
499 | distributed printing into two object types: | |
500 | ||
501 | - Printer (Section 2.1) | |
502 | - Job (Section 2.2) | |
503 | ||
504 | ||
505 | ||
506 | deBry, et al. Experimental [Page 9] | |
507 | \f | |
508 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
509 | ||
510 | ||
511 | Each object type has an associated set of operations (see section 3) | |
512 | and attributes (see section 4). | |
513 | ||
514 | It is important, however, to understand that in real system | |
515 | implementations (which lie underneath the abstracted IPP/1.0 model), | |
516 | there are other components of a print service which are not | |
517 | explicitly defined in the IPP/1.0 model. The following figure | |
518 | illustrates where IPP/1.0 fits with respect to these other | |
519 | components. | |
520 | ||
521 | +--------------+ | |
522 | | Application | | |
523 | o +. . . . . . . | | |
524 | \|/ | Spooler | | |
525 | / \ +. . . . . . . | +---------+ | |
526 | End-User | Print Driver |---| File | | |
527 | +-----------+ +-----+ +------+-------+ +----+----+ | |
528 | | Browser | | GUI | | | | |
529 | +-----+-----+ +--+--+ | | | |
530 | | | | | | |
531 | | +---+------------+---+ | | |
532 | N D S | | IPP Client |------------+ | |
533 | O I E | +---------+----------+ | |
534 | T R C | | | |
535 | I E U | | |
536 | F C R -------------- Transport ------------------ | |
537 | I T I | |
538 | C O T | --+ | |
539 | A R Y +--------+--------+ | | |
540 | T Y | IPP Server | | | |
541 | I +--------+--------+ | | |
542 | O | | | |
543 | N +-----------------+ | IPP Printer | |
544 | | Print Service | | | |
545 | +-----------------+ | | |
546 | | --+ | |
547 | +-----------------+ | |
548 | | Output Device(s)| | |
549 | +-----------------+ | |
550 | ||
551 | An IPP Printer object encapsulates the functions normally associated | |
552 | with physical output devices along with the spooling, scheduling and | |
553 | multiple device management functions often associated with a print | |
554 | server. Printer objects are optionally registered as entries in a | |
555 | directory where end users find and select them based on some sort of | |
556 | filtered and context based searching mechanism (see section 16). The | |
557 | directory is used to store relatively static information about the | |
558 | Printer, allowing end users to search for and find Printers that | |
559 | ||
560 | ||
561 | ||
562 | deBry, et al. Experimental [Page 10] | |
563 | \f | |
564 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
565 | ||
566 | ||
567 | match their search criteria, for example: name, context, printer | |
568 | capabilities, etc. The more dynamic information, such as state, | |
569 | currently loaded and ready media, number of jobs at the Printer, | |
570 | errors, warnings, and so forth, is directly associated with the | |
571 | Printer object itself rather than with the entry in the directory | |
572 | which only represents the Printer object. | |
573 | ||
574 | IPP clients implement the IPP protocol on the client side and give | |
575 | end users (or programs running on behalf of end users) the ability to | |
576 | query Printer objects and submit and manage print jobs. An IPP | |
577 | server is just that part of the Printer object that implements the | |
578 | server-side protocol. The rest of the Printer object implements (or | |
579 | gateways into) the application semantics of the print service itself. | |
580 | The Printer objects may be embedded in an output device or may be | |
581 | implemented on a host on the network that communicates with an output | |
582 | device. | |
583 | ||
584 | When a job is submitted to the Printer object and the Printer object | |
585 | validates the attributes in the submission request, the Printer | |
586 | object creates a new Job object. The end user then interacts with | |
587 | this new Job object to query its status and monitor the progress of | |
588 | the job. End users may also cancel the print job by using the Job | |
589 | object's Cancel-Job operation. The notification service is out of | |
590 | scope for IPP/1.0, but using such a notification service, the end | |
591 | user is able to register for and receive Printer specific and Job | |
592 | specific events. An end user can query the status of Printer objects | |
593 | and can follow the progress of Job objects by polling using the Get- | |
594 | Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations. | |
595 | ||
596 | 2. IPP Objects | |
597 | ||
598 | The IPP/1.0 model introduces objects of type Printer and Job. Each | |
599 | type of object models relevant aspects of a real-world entity such as | |
600 | a real printer or real print job. Each object type is defined as a | |
601 | set of possible attributes that may be supported by instances of that | |
602 | object type. For each object (instance), the actual set of supported | |
603 | attributes and values describe a specific implementation. The | |
604 | object's attributes and values describe its state, capabilities, | |
605 | realizable features, job processing functions, and default behaviors | |
606 | and characteristics. For example, the Printer object type is defined | |
607 | as a set of attributes that each Printer object potentially supports. | |
608 | In the same manner, the Job object type is defined as a set of | |
609 | attributes that are potentially supported by each Job object. | |
610 | ||
611 | Each attribute included in the set of attributes defining an object | |
612 | type is labeled as: | |
613 | ||
614 | ||
615 | ||
616 | ||
617 | ||
618 | deBry, et al. Experimental [Page 11] | |
619 | \f | |
620 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
621 | ||
622 | ||
623 | - "REQUIRED": each object MUST support the attribute. | |
624 | - "OPTIONAL": each object MAY support the attribute. | |
625 | ||
626 | There is no such similar labeling of attribute values. However, if | |
627 | an implementation supports an attribute, it MUST support at least one | |
628 | of the possible values for that attribute. | |
629 | ||
630 | 2.1 Printer Object | |
631 | ||
632 | The major component of the IPP/1.0 model is the Printer object. A | |
633 | Printer object implements the server-side of the IPP/1.0 protocol. | |
634 | Using the protocol, end users may query the attributes of the Printer | |
635 | object and submit print jobs to the Printer object. The actual | |
636 | implementation components behind the Printer abstraction may take on | |
637 | different forms and different configurations. However, the model | |
638 | abstraction allows the details of the configuration of real | |
639 | components to remain opaque to the end user. Section 3 describes | |
640 | each of the Printer operations in detail. | |
641 | ||
642 | The capabilities and state of a Printer object are described by its | |
643 | attributes. Printer attributes are divided into two groups: | |
644 | ||
645 | - "job-template" attributes: These attributes describe supported | |
646 | job processing capabilities and defaults for the Printer object. | |
647 | (See section 4.2) | |
648 | - "printer-description" attributes: These attributes describe the | |
649 | Printer object's identification, state, location, references to | |
650 | other sources of information about the Printer object, etc. (see | |
651 | section 4.4) | |
652 | ||
653 | Since a Printer object is an abstraction of a generic document output | |
654 | device and print service provider, a Printer object could be used to | |
655 | represent any real or virtual device with semantics consistent with | |
656 | the Printer object, such as a fax device, an imager, or even a CD | |
657 | writer. | |
658 | ||
659 | Some examples of configurations supporting a Printer object include: | |
660 | ||
661 | 1) An output device with no spooling capabilities | |
662 | 2) An output device with a built-in spooler | |
663 | 3) A print server supporting IPP with one or more associated output | |
664 | devices | |
665 | 3a) The associated output devices may or may not be capable of | |
666 | spooling jobs | |
667 | 3b) The associated output devices may or may not support IPP | |
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | deBry, et al. Experimental [Page 12] | |
675 | \f | |
676 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
677 | ||
678 | ||
679 | The following figures show some examples of how Printer objects can | |
680 | be realized on top of various distributed printing configurations. | |
681 | The embedded case below represents configurations 1 and 2. The hosted | |
682 | and fan-out figures below represent configurations 3a and 3b. | |
683 | ||
684 | Legend: | |
685 | ||
686 | ##### indicates a Printer object which is | |
687 | either embedded in an output device or is | |
688 | hosted in a server. The Printer object | |
689 | might or might not be capable of queuing/spooling. | |
690 | ||
691 | any indicates any network protocol or direct | |
692 | connect, including IPP | |
693 | ||
694 | ||
695 | embedded printer: | |
696 | output device | |
697 | +---------------+ | |
698 | O +--------+ | ########### | | |
699 | /|\ | client |------------IPP------------># Printer # | | |
700 | / \ +--------+ | # Object # | | |
701 | | ########### | | |
702 | +---------------+ | |
703 | ||
704 | ||
705 | hosted printer: | |
706 | +---------------+ | |
707 | O +--------+ ########### | | | |
708 | /|\ | client |--IPP--># Printer #-any->| output device | | |
709 | / \ +--------+ # Object # | | | |
710 | ########### +---------------+ | |
711 | ||
712 | ||
713 | ||
714 | +---------------+ | |
715 | fan out: | | | |
716 | +-->| output device | | |
717 | any/ | | | |
718 | O +--------+ ########### / +---------------+ | |
719 | /|\ | client |-IPP-># Printer #--* | |
720 | / \ +--------+ # Object # \ +---------------+ | |
721 | ########### any\ | | | |
722 | +-->| output device | | |
723 | | | | |
724 | +---------------+ | |
725 | ||
726 | ||
727 | ||
728 | ||
729 | ||
730 | deBry, et al. Experimental [Page 13] | |
731 | \f | |
732 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
733 | ||
734 | ||
735 | 2.2 Job Object | |
736 | ||
737 | A Job object is used to model a print job. A Job object contains | |
738 | documents. The information required to create a Job object is sent | |
739 | in a create request from the end user via an IPP Client to the | |
740 | Printer object. The Printer object validates the create request, and | |
741 | if the Printer object accepts the request, the Printer object creates | |
742 | the new Job object. Section 3 describes each of the Job operations | |
743 | in detail. | |
744 | ||
745 | The characteristics and state of a Job object are described by its | |
746 | attributes. Job attributes are grouped into two groups as follows: | |
747 | ||
748 | - "job-template" attributes: These attributes can be supplied by | |
749 | the client or end user and include job processing instructions | |
750 | which are intended to override any Printer object defaults and/or | |
751 | instructions embedded within the document data. (See section 4.2) | |
752 | - "job-description" attributes: These attributes describe the Job | |
753 | object's identification, state, size, etc. The client supplies | |
754 | some of these attributes, and the Printer object generates others. | |
755 | (See section 4.3) | |
756 | ||
757 | An implementation MUST support at least one document per Job object. | |
758 | An implementation MAY support multiple documents per Job object. A | |
759 | document is either: | |
760 | ||
761 | - a stream of document data in a format supported by the Printer | |
762 | object (typically a Page Description Language - PDL), or | |
763 | - a reference to such a stream of document data | |
764 | ||
765 | In IPP/1.0, a document is not modeled as an IPP object, therefore it | |
766 | has no object identifier or associated attributes. All job | |
767 | processing instructions are modeled as Job object attributes. These | |
768 | attributes are called Job Template attributes and they apply equally | |
769 | to all documents within a Job object. | |
770 | ||
771 | 2.3 Object Relationships | |
772 | ||
773 | IPP objects have relationships that are maintained persistently along | |
774 | with the persistent storage of the object attributes. | |
775 | ||
776 | A Printer object can represent either one or more physical output | |
777 | devices or a logical device which "processes" jobs but never actually | |
778 | uses a physical output device to put marks on paper. Examples of | |
779 | logical devices include a Web page publisher or a gateway into an | |
780 | online document archive or repository. A Printer object contains | |
781 | zero or more Job objects. | |
782 | ||
783 | ||
784 | ||
785 | ||
786 | deBry, et al. Experimental [Page 14] | |
787 | \f | |
788 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
789 | ||
790 | ||
791 | A Job object is contained by exactly one Printer object, however the | |
792 | identical document data associated with a Job object could be sent to | |
793 | either the same or a different Printer object. In this case, a | |
794 | second Job object would be created which would be almost identical to | |
795 | the first Job object, however it would have new (different) Job | |
796 | object identifiers (see section 2.4). | |
797 | ||
798 | A Job object is either empty (before any documents have been added) | |
799 | or contains one or more documents. If the contained document is a | |
800 | stream of document data, that stream can be contained in only one | |
801 | document. However, there can be identical copies of the stream in | |
802 | other documents in the same or different Job objects. If the | |
803 | contained document is just a reference to a stream of document data, | |
804 | other documents (in the same or different Job object(s)) may contain | |
805 | the same reference. | |
806 | ||
807 | 2.4 Object Identity | |
808 | ||
809 | All Printer and Job objects are identified by a Uniform Resource | |
810 | Identifier (URI) [RFC2396] so that they can be persistently and | |
811 | unambiguously referenced. The notion of a URI is a useful concept, | |
812 | however, until the notion of URI is more stable (i.e., defined more | |
813 | completely and deployed more widely), it is expected that the URIs | |
814 | used for IPP objects will actually be URLs [RFC2396]. Since every | |
815 | URL is a specialized form of a URI, even though the more generic term | |
816 | URI is used throughout the rest of this document, its usage is | |
817 | intended to cover the more specific notion of URL as well. | |
818 | ||
819 | An administrator configures Printer objects to either support or not | |
820 | support authentication and/or message privacy using SSL3 [SSL] (the | |
821 | mechanism for security configuration is outside the scope of | |
822 | IPP/1.0). In some situations, both types of connections (both | |
823 | authenticated and unauthenticated) can be established using a single | |
824 | communication channel that has some sort of negotiation mechanism. | |
825 | In other situations, multiple communication channels are used, one | |
826 | for each type of security configuration. Section 8 provides a full | |
827 | description of all security considerations and configurations. | |
828 | ||
829 | If a Printer object supports more than one communication channel, | |
830 | some or all of those channels might support and/or require different | |
831 | security mechanisms. In such cases, an administrator could expose | |
832 | the simultaneous support for these multiple communication channels as | |
833 | multiple URIs for a single Printer object where each URI represents | |
834 | one of the communication channels to the Printer object. To support | |
835 | this flexibility, the IPP Printer object type defines a multi-valued | |
836 | identification attribute called the "printer-uri-supported" | |
837 | attribute. It MUST contain at least one URI. It MAY contain more | |
838 | than one URI. That is, every Printer object will have at least one | |
839 | ||
840 | ||
841 | ||
842 | deBry, et al. Experimental [Page 15] | |
843 | \f | |
844 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
845 | ||
846 | ||
847 | URI that identifies at least one communication channel to the Printer | |
848 | object, but it may have more than one URI where each URI identifies a | |
849 | different communication channel to the Printer object. The | |
850 | "printer-uri-supported" attribute has a companion attribute, the | |
851 | "uri-security-supported" attribute, that has the same cardinality as | |
852 | "printer-uri-supported". The purpose of the "uri-security-supported" | |
853 | attribute is to indicate the security mechanisms (if any) used for | |
854 | each URI listed in "printer-uri-supported". These two attributes are | |
855 | fully described in sections 4.4.1 and 4.4.2. | |
856 | ||
857 | When a job is submitted to the Printer object via a create request, | |
858 | the client supplies only a single Printer object URI. The client | |
859 | supplied Printer object URI MUST be one of the values in the | |
860 | "printer-uri-supported" Printer attribute. | |
861 | ||
862 | Note: IPP/1.0 does not specify how the client obtains the client | |
863 | supplied URI, but it is RECOMMENDED that a Printer object be | |
864 | registered as an entry in a directory service. End-users and | |
865 | programs can then interrogate the directory searching for Printers. | |
866 | Section 16 defines a generic schema for Printer object entries in the | |
867 | directory service and describes how the entry acts as a bridge to the | |
868 | actual IPP Printer object. The entry in the directory that | |
869 | represents the IPP Printer object includes the possibly many URIs for | |
870 | that Printer object as values in one its attributes. | |
871 | ||
872 | When a client submits a create request to the Printer object, the | |
873 | Printer object validates the request and creates a new Job object. | |
874 | The Printer object assigns the new Job object a URI which is stored | |
875 | in the "job-uri" Job attribute. This URI is then used by clients as | |
876 | the target for subsequent Job operations. The Printer object | |
877 | generates a Job URI based on its configured security policy and the | |
878 | URI used by the client in the create request. | |
879 | ||
880 | For example, consider a Printer object that supports both a | |
881 | communication channel secured by the use of SSL3 (using HTTP over | |
882 | SSL3 with an "https" schemed URI) and another open communication | |
883 | channel that is not secured with SSL3 (using a simple "http" schemed | |
884 | URI). If a client were to submit a job using the secure URI, the | |
885 | Printer object would assign the new Job object a secure URI as well. | |
886 | If a client were to submit a job using the open-channel URI, the | |
887 | Printer would assign the new Job object an open-channel URI. | |
888 | ||
889 | In addition, the Printer object also populates the Job object's | |
890 | "job-printer-uri" attribute. This is a reference back to the Printer | |
891 | object that created the Job object. If a client only has access to a | |
892 | Job object's "job-uri" identifier, the client can query the Job's | |
893 | "job-printer-uri" attribute in order to determine which Printer | |
894 | object created the Job object. If the Printer object supports more | |
895 | ||
896 | ||
897 | ||
898 | deBry, et al. Experimental [Page 16] | |
899 | \f | |
900 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
901 | ||
902 | ||
903 | than one URI, the Printer object picks the one URI supplied by the | |
904 | client when creating the job to build the value for and to populate | |
905 | the Job's "job-printer-uri" attribute. | |
906 | ||
907 | Allowing Job objects to have URIs allows for flexibility and | |
908 | scalability. For example, in some implementations, the Printer | |
909 | object might create Jobs that are processed in the same local | |
910 | environment as the Printer object itself. In this case, the Job URI | |
911 | might just be a composition of the Printer's URI and some unique | |
912 | component for the Job object, such as the unique 32-bit positive | |
913 | integer mentioned later in this paragraph. In other implementations, | |
914 | the Printer object might be a central clearing-house for validating | |
915 | all Job object creation requests, but the Job object itself might be | |
916 | created in some environment that is remote from the Printer object. | |
917 | In this case, the Job object's URI may have no physical-location | |
918 | relationship at all to the Printer object's URI. Again, the fact | |
919 | that Job objects have URIs allows for flexibility and scalability, | |
920 | however, many existing printing systems have local models or | |
921 | interface constraints that force print jobs to be identified using | |
922 | only a 32-bit positive integer rather than an independent URI. This | |
923 | numeric Job ID is only unique within the context of the Printer | |
924 | object to which the create request was originally submitted. | |
925 | Therefore, in order to allow both types of client access to IPP Job | |
926 | objects (either by Job URI or by numeric Job ID), when the Printer | |
927 | object successfully processes a create request and creates a new Job | |
928 | object, the Printer object MUST generate both a Job URI and a Job ID. | |
929 | The Job ID (stored in the "job-id" attribute) only has meaning in the | |
930 | context of the Printer object to which the create request was | |
931 | originally submitted. This requirement to support both Job URIs and | |
932 | Job IDs allows all types of clients to access Printer objects and Job | |
933 | objects no matter the local constraints imposed on the client | |
934 | implementation. | |
935 | ||
936 | In addition to identifiers, Printer objects and Job objects have | |
937 | names ("printer-name" and "job-name"). An object name NEED NOT be | |
938 | unique across all instances of all objects. A Printer object's name | |
939 | is chosen and set by an administrator through some mechanism outside | |
940 | the scope of IPP/1.0. A Job object's name is optionally chosen and | |
941 | supplied by the IPP client submitting the job. If the client does | |
942 | not supply a Job object name, the Printer object generates a name for | |
943 | the new Job object. In all cases, the name only has local meaning. | |
944 | ||
945 | To summarize: | |
946 | ||
947 | - Each Printer object is identified with one or more URIs. The | |
948 | Printer's "printer-uri-supported" attribute contains the URI(s). | |
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | deBry, et al. Experimental [Page 17] | |
955 | \f | |
956 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
957 | ||
958 | ||
959 | - The Printer object's "uri-security-supported" attribute | |
960 | identifies the communication channel security protocols that may | |
961 | or may not have been configured for the various Printer object | |
962 | URIs (e.g., 'ssl3' or 'none'). | |
963 | - Each Job object is identified with a Job URI. The Job's "job-uri" | |
964 | attribute contains the URI. | |
965 | - Each Job object is also identified with Job ID which is a 32-bit, | |
966 | positive integer. The Job's "job-id" attribute contains the Job | |
967 | ID. The Job ID is only unique within the context of the Printer | |
968 | object which created the Job object. | |
969 | - Each Job object has a "job-printer-uri" attribute which contains | |
970 | the URI of the Printer object that was used to create the Job | |
971 | object. This attribute is used to determine the Printer object | |
972 | that created a Job object when given only the URI for the Job | |
973 | object. This linkage is necessary to determine the languages, | |
974 | charsets, and operations which are supported on that Job (the | |
975 | basis for such support comes from the creating Printer object). | |
976 | - Each Printer object has a name (which is not necessarily unique). | |
977 | The administrator chooses and sets this name through some | |
978 | mechanism outside the scope of IPP/1.0 itself. The Printer | |
979 | object's "printer-name" attribute contains the name. | |
980 | - Each Job object has a name (which is not necessarily unique). The | |
981 | client optionally supplies this name in the create request. If | |
982 | the client does not supply this name, the Printer object generates | |
983 | a name for the Job object. The Job object's "job-name" attribute | |
984 | contains the name. | |
985 | ||
986 | 3. IPP Operations | |
987 | ||
988 | IPP objects support operations. An operation consists of a request | |
989 | and a response. When a client communicates with an IPP object, the | |
990 | client issues an operation request to the URI for that object. | |
991 | Operation requests and responses have parameters that identify the | |
992 | operation. Operations also have attributes that affect the run-time | |
993 | characteristics of the operation (the intended target, localization | |
994 | information, etc.). These operation-specific attributes are called | |
995 | operation attributes (as compared to object attributes such as | |
996 | Printer object attributes or Job object attributes). Each request | |
997 | carries along with it any operation attributes, object attributes, | |
998 | and/or document data required to perform the operation. Each request | |
999 | requires a response from the object. Each response indicates success | |
1000 | or failure of the operation with a status code as a response | |
1001 | parameter. The response contains any operation attributes, object | |
1002 | attributes, and/or status messages generated during the execution of | |
1003 | the operation request. | |
1004 | ||
1005 | ||
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | deBry, et al. Experimental [Page 18] | |
1011 | \f | |
1012 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1013 | ||
1014 | ||
1015 | This section describes the semantics of the IPP operations, both | |
1016 | requests and responses, in terms of the parameters, attributes, and | |
1017 | other data associated with each operation. | |
1018 | ||
1019 | The IPP/1.0 Printer operations are: | |
1020 | ||
1021 | Print-Job (section 3.2.1) | |
1022 | Print-URI (section 3.2.2) | |
1023 | Validate-Job (section 3.2.3) | |
1024 | Create-Job (section 3.2.4) | |
1025 | Get-Printer-Attributes (section 3.2.5) | |
1026 | Get-Jobs (section 3.2.6) | |
1027 | ||
1028 | The Job operations are: | |
1029 | ||
1030 | Send-Document (section 3.3.1) | |
1031 | Send-URI (section 3.3.2) | |
1032 | Cancel-Job (section 3.3.3) | |
1033 | Get-Job-Attributes (section 3.3.4) | |
1034 | ||
1035 | The Send-Document and Send-URI Job operations are used to add a new | |
1036 | document to an existing multi-document Job object created using the | |
1037 | Create-Job operation. | |
1038 | ||
1039 | 3.1 Common Semantics | |
1040 | ||
1041 | All IPP operations require some common parameters and operation | |
1042 | attributes. These common elements and their semantic characteristics | |
1043 | are defined and described in more detail in the following sections. | |
1044 | ||
1045 | 3.1.1 Required Parameters | |
1046 | ||
1047 | Every operation request contains the following REQUIRED parameters: | |
1048 | ||
1049 | - a "version-number", | |
1050 | - an "operation-id", | |
1051 | - a "request-id", and | |
1052 | - the attributes that are REQUIRED for that type of request. | |
1053 | ||
1054 | Every operation response contains the following REQUIRED parameters: | |
1055 | ||
1056 | - a "version-number", | |
1057 | - a "status-code", | |
1058 | - the "request-id" that was supplied in the corresponding request, | |
1059 | and | |
1060 | - the attributes that are REQUIRED for that type of response. | |
1061 | ||
1062 | ||
1063 | ||
1064 | ||
1065 | ||
1066 | deBry, et al. Experimental [Page 19] | |
1067 | \f | |
1068 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1069 | ||
1070 | ||
1071 | The encoding and transport document [RFC2565] defines special rules | |
1072 | for the encoding of these parameters. All other operation elements | |
1073 | are represented using the more generic encoding rules for attributes | |
1074 | and groups of attributes. | |
1075 | ||
1076 | 3.1.2 Operation IDs and Request IDs | |
1077 | ||
1078 | Each IPP operation request includes an identifying "operation-id" | |
1079 | value. Valid values are defined in the "operations-supported" | |
1080 | Printer attribute section (see section 4.4.13). The client specifies | |
1081 | which operation is being requested by supplying the correct | |
1082 | "operation-id" value. | |
1083 | ||
1084 | In addition, every invocation of an operation is identified by a | |
1085 | "request-id" value. For each request, the client chooses the | |
1086 | "request-id" which MUST be an integer (possibly unique depending on | |
1087 | client requirements) in the range from 1 to 2**31 - 1 (inclusive). | |
1088 | This "request-id" allows clients to manage multiple outstanding | |
1089 | requests. The receiving IPP object copies all 32-bits of the client- | |
1090 | supplied "request-id" attribute into the response so that the client | |
1091 | can match the response with the correct outstanding request, even if | |
1092 | the "request-id" is out of range. If the request is terminated | |
1093 | before the complete "request-id" is received, the IPP object rejects | |
1094 | the request and returns a response with a "request-id" of 0. | |
1095 | ||
1096 | Note: In some cases, the transport protocol underneath IPP might be a | |
1097 | connection oriented protocol that would make it impossible for a | |
1098 | client to receive responses in any order other than the order in | |
1099 | which the corresponding requests were sent. In such cases, the | |
1100 | "request-id" attribute would not be essential for correct protocol | |
1101 | operation. However, in other mappings, the operation responses can | |
1102 | come back in any order. In these cases, the "request-id" would be | |
1103 | essential. | |
1104 | ||
1105 | 3.1.3 Attributes | |
1106 | ||
1107 | Operation requests and responses are both composed of groups of | |
1108 | attributes and/or document data. The attributes groups are: | |
1109 | ||
1110 | - Operation Attributes: These attributes are passed in the | |
1111 | operation and affect the IPP object's behavior while processing | |
1112 | the operation request and may affect other attributes or groups | |
1113 | of attributes. Some operation attributes describe the document | |
1114 | data associated with the print job and are associated with new | |
1115 | Job objects, however most operation attributes do not persist | |
1116 | beyond the life of the operation. The description of each | |
1117 | operation attribute includes conformance statements indicating | |
1118 | which operation attributes are REQUIRED and which are OPTIONAL | |
1119 | ||
1120 | ||
1121 | ||
1122 | deBry, et al. Experimental [Page 20] | |
1123 | \f | |
1124 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1125 | ||
1126 | ||
1127 | for an IPP object to support and which attributes a client MUST | |
1128 | supply in a request and an IPP object MUST supply in a response. | |
1129 | - Job Template Attributes: These attributes affect the processing | |
1130 | of a job. A client OPTIONALLY supplies Job Template Attributes | |
1131 | in a create request, and the receiving object MUST be prepared to | |
1132 | receive all supported attributes. The Job object can later be | |
1133 | queried to find out what Job Template attributes were originally | |
1134 | requested in the create request, and such attributes are returned | |
1135 | in the response as Job Object Attributes. The Printer object can | |
1136 | be queried about its Job Template attributes to find out what | |
1137 | type of job processing capabilities are supported and/or what the | |
1138 | default job processing behaviors are, though such attributes are | |
1139 | returned in the response as Printer Object Attributes. The | |
1140 | "ipp-attribute-fidelity" operation attribute affects processing | |
1141 | of all client-supplied Job Template attributes (see section 15 | |
1142 | for a full description of "ipp-attribute-fidelity" and its | |
1143 | relationship to other attributes). | |
1144 | - Job Object Attributes: These attributes are returned in response | |
1145 | to a query operation directed at a Job object. | |
1146 | - Printer Object Attributes: These attributes are returned in | |
1147 | response to a query operation directed at a Printer object. | |
1148 | - Unsupported Attributes: In a create request, the client supplies | |
1149 | a set of Operation and Job Template attributes. If any of these | |
1150 | attributes or their values is unsupported by the Printer object, | |
1151 | the Printer object returns the set of unsupported attributes in | |
1152 | the response. Section 15 gives a full description of how Job | |
1153 | Template attributes supplied by the client in a create request | |
1154 | are processed by the Printer object and how unsupported | |
1155 | attributes are returned to the client. Because of extensibility, | |
1156 | any IPP object might receive a request that contains new or | |
1157 | unknown attributes or values for which it has no support. In such | |
1158 | cases, the IPP object processes what it can and returns the | |
1159 | unsupported attributes in the response. | |
1160 | ||
1161 | Later in this section, each operation is formally defined by | |
1162 | identifying the allowed and expected groups of attributes for each | |
1163 | request and response. The model identifies a specific order for each | |
1164 | group in each request or response, but the attributes within each | |
1165 | group may be in any order, unless specified otherwise. | |
1166 | ||
1167 | Each attribute specification includes the attribute's name followed | |
1168 | by the name of its attribute syntax(es) in parenthesizes. In | |
1169 | addition, each 'integer' attribute is followed by the allowed range | |
1170 | in parentheses, (m:n), for values of that attribute. Each 'text' or | |
1171 | 'name' attribute is followed by the maximum size in octets in | |
1172 | parentheses, (size), for values of that attribute. For more details | |
1173 | on attribute syntax notation, see the descriptions of these | |
1174 | attributes syntaxes in section 4.1. | |
1175 | ||
1176 | ||
1177 | ||
1178 | deBry, et al. Experimental [Page 21] | |
1179 | \f | |
1180 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1181 | ||
1182 | ||
1183 | Note: Document data included in the operation is not strictly an | |
1184 | attribute, but it is treated as a special attribute group for | |
1185 | ordering purposes. The only operations that support supplying the | |
1186 | document data within an operation request are Print-Job and Send- | |
1187 | Document. There are no operation responses that include document | |
1188 | data. | |
1189 | ||
1190 | Note: Some operations are REQUIRED for IPP objects to support; the | |
1191 | others are OPTIONAL (see section 5.2.2). Therefore, before using an | |
1192 | OPTIONAL operation, a client SHOULD first use the REQUIRED Get- | |
1193 | Printer-Attributes operation to query the Printer's "operations- | |
1194 | supported" attribute in order to determine which OPTIONAL Printer and | |
1195 | Job operations are actually supported. The client SHOULD NOT use an | |
1196 | OPTIONAL operation that is not supported. When an IPP object | |
1197 | receives a request to perform an operation it does not support, it | |
1198 | returns the 'server-error-operation-not-supported' status code (see | |
1199 | section 13.1.5.2). An IPP object is non-conformant if it does not | |
1200 | support a REQUIRED operation. | |
1201 | ||
1202 | 3.1.4 Character Set and Natural Language Operation Attributes | |
1203 | ||
1204 | Some Job and Printer attributes have values that are text strings and | |
1205 | names intended for human understanding rather than machine | |
1206 | understanding (see the 'text' and 'name' attribute syntax | |
1207 | descriptions in section 4.1). The following sections describe two | |
1208 | special Operation Attributes called "attributes-charset" and | |
1209 | "attributes-natural-language". These attributes are always part of | |
1210 | the Operation Attributes group. For most attribute groups, the order | |
1211 | of the attributes within the group is not important. However, for | |
1212 | these two attributes within the Operation Attributes group, the order | |
1213 | is critical. The "attributes-charset" attribute MUST be the first | |
1214 | attribute in the group and the "attributes-natural-language" | |
1215 | attribute MUST be the second attribute in the group. In other words, | |
1216 | these attributes MUST be supplied in every IPP request and response, | |
1217 | they MUST come first in the group, and MUST come in the specified | |
1218 | order. For job creation operations, the IPP Printer implementation | |
1219 | saves these two attributes with the new Job object as Job Description | |
1220 | attributes. For the sake of brevity in this document, these | |
1221 | operation attribute descriptions are not repeated with every | |
1222 | operation request and response, but have a reference back to this | |
1223 | section instead. | |
1224 | ||
1225 | 3.1.4.1 Request Operation Attributes | |
1226 | ||
1227 | The client MUST supply and the Printer object MUST support the | |
1228 | following REQUIRED operation attributes in every IPP/1.0 operation | |
1229 | request: | |
1230 | ||
1231 | ||
1232 | ||
1233 | ||
1234 | deBry, et al. Experimental [Page 22] | |
1235 | \f | |
1236 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1237 | ||
1238 | ||
1239 | "attributes-charset" (charset): | |
1240 | This operation attribute identifies the charset (coded character | |
1241 | set and encoding method) used by any 'text' and 'name' | |
1242 | attributes that the client is supplying in this request. It | |
1243 | also identifies the charset that the Printer object MUST use (if | |
1244 | supported) for all 'text' and 'name' attributes and status | |
1245 | messages that the Printer object returns in the response to this | |
1246 | request. See Sections 4.1.1 and 4.1.2 for the specification of | |
1247 | the 'text' and 'name' attribute syntaxes. | |
1248 | ||
1249 | All clients and IPP objects MUST support the 'utf-8' charset | |
1250 | [RFC2279] and MAY support additional charsets provided that they | |
1251 | are registered with IANA [IANA-CS]. If the Printer object does | |
1252 | not support the client supplied charset value, the Printer | |
1253 | object MUST reject the request, set the "attributes-charset" to | |
1254 | 'utf-8' in the response, and return the 'client-error-charset- | |
1255 | not-supported' status code and any 'text' or 'name' attributes | |
1256 | using the 'utf-8' charset. The Printer object MUST indicate the | |
1257 | charset(s) supported as the values of the "charset-supported" | |
1258 | Printer attribute (see Section 4.4.15), so that the client can | |
1259 | query to determine which charset(s) are supported. | |
1260 | ||
1261 | Note to client implementers: Since IPP objects are only required | |
1262 | to support the 'utf-8' charset, in order to maximize | |
1263 | interoperability with multiple IPP object implementations, a | |
1264 | client may want to supply 'utf-8' in the "attributes-charset" | |
1265 | operation attribute, even though the client is only passing and | |
1266 | able to present a simpler charset, such as US-ASCII or ISO- | |
1267 | 8859-1. Then the client will have to filter out (or charset | |
1268 | convert) those characters that are returned in the response that | |
1269 | it cannot present to its user. On the other hand, if both the | |
1270 | client and the IPP objects also support a charset in common | |
1271 | besides utf-8, the client may want to use that charset in order | |
1272 | to avoid charset conversion or data loss. | |
1273 | ||
1274 | See the 'charset' attribute syntax description in Section 4.1.7 | |
1275 | for the syntax and semantic interpretation of the values of this | |
1276 | attribute and for example values. | |
1277 | ||
1278 | "attributes-natural-language" (naturalLanguage): | |
1279 | This operation attribute identifies the natural language used by | |
1280 | any 'text' and 'name' attributes that the client is supplying in | |
1281 | this request. This attribute also identifies the natural | |
1282 | language that the Printer object SHOULD use for all 'text' and ' | |
1283 | name' attributes and status messages that the Printer object | |
1284 | returns in the response to this request. | |
1285 | ||
1286 | ||
1287 | ||
1288 | ||
1289 | ||
1290 | deBry, et al. Experimental [Page 23] | |
1291 | \f | |
1292 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1293 | ||
1294 | ||
1295 | There are no REQUIRED natural languages required for the Printer | |
1296 | object to support. However, the Printer object's "generated- | |
1297 | natural-language-supported" attribute identifies the natural | |
1298 | languages supported by the Printer object and any contained Job | |
1299 | objects for all text strings generated by the IPP object. A | |
1300 | client MAY query this attribute to determine which natural | |
1301 | language(s) are supported for generated messages. | |
1302 | ||
1303 | For any of the attributes for which the Printer object generates | |
1304 | text, i.e., for the "job-state-message", "printer-state- | |
1305 | message", and status messages (see Section 3.1.6), the Printer | |
1306 | object MUST be able to generate these text strings in any of its | |
1307 | supported natural languages. If the client requests a natural | |
1308 | language that is not supported, the Printer object MUST return | |
1309 | these generated messages in the Printer's configured natural | |
1310 | language as specified by the Printer's "natural-language- | |
1311 | configured" attribute" (see Section 4.4.16). | |
1312 | ||
1313 | For other 'text' and 'name' attributes supplied by the client, | |
1314 | authentication system, operator, system administrator, or | |
1315 | manufacturer (i.e., for "job-originating-user-name", "printer- | |
1316 | name" (name), "printer-location" (text), "printer-info" (text), | |
1317 | and "printer-make-and-model" (text)), the Printer object is only | |
1318 | required to support the configured natural language of the | |
1319 | Printer identified by the Printer object's "natural-language- | |
1320 | configured" attribute, though support of additional natural | |
1321 | languages for these attributes is permitted. | |
1322 | ||
1323 | For any 'text' or 'name' attribute in the request that is in a | |
1324 | different natural language than the value supplied in the | |
1325 | "attributes-natural-language" operation attribute, the client | |
1326 | MUST use the Natural Language Override mechanism (see sections | |
1327 | 4.1.1.2 and 4.1.2.2) for each such attribute value supplied. | |
1328 | The client MAY use the Natural Language Override mechanism | |
1329 | redundantly, i.e., use it even when the value is in the same | |
1330 | natural language as the value supplied in the "attributes- | |
1331 | natural-language" operation attribute of the request. | |
1332 | ||
1333 | The IPP object MUST accept any natural language and any Natural | |
1334 | Language Override, whether the IPP object supports that natural | |
1335 | language or not (and independent of the value of the "ipp- | |
1336 | attribute-fidelity" Operation attribute). That is the IPP | |
1337 | object accepts all client supplied values no matter what the | |
1338 | values are in the Printer object's "generated-natural-language- | |
1339 | supported" attribute. That attribute, "generated-natural- | |
1340 | language-supported", only applies to generated messages, | |
1341 | ||
1342 | ||
1343 | ||
1344 | ||
1345 | ||
1346 | deBry, et al. Experimental [Page 24] | |
1347 | \f | |
1348 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1349 | ||
1350 | ||
1351 | not client supplied messages. The IPP object MUST remember that | |
1352 | natural language for all client-supplied attributes, and when | |
1353 | returning those attributes in response to a query, the IPP | |
1354 | object MUST indicate that natural language. | |
1355 | ||
1356 | Each value whose attribute syntax type is 'text' or 'name' (see | |
1357 | sections 4.1.1 and 4.1.2) has an Associated Natural-Language. | |
1358 | This document does not specify how this association is stored in | |
1359 | a Printer or Job object. When such a value is encoded in a | |
1360 | request or response, the natural language is either implicit or | |
1361 | explicit: | |
1362 | ||
1363 | - In the implicit case, the value contains only the | |
1364 | text/name value, and the language is specified by the | |
1365 | "attributes-natural-language" operation attribute in the | |
1366 | request or response (see sections 4.1.1.1 | |
1367 | textWithoutLanguage and 4.1.2.1 nameWithoutLanguage). | |
1368 | ||
1369 | - In the explicit case (also known as the Natural-Language | |
1370 | Override case), the value contains both the language and | |
1371 | the text/name value (see sections 4.1.1.2 | |
1372 | textWithLanguage and 4.1.2.2 nameWithLanguage). | |
1373 | ||
1374 | For example, the "job-name" attribute MAY be supplied by the | |
1375 | client in a create request. The text value for this attribute | |
1376 | will be in the natural language identified by the "attribute- | |
1377 | natural-language" attribute, or if different, as identified by | |
1378 | the Natural Language Override mechanism. If supplied, the IPP | |
1379 | object will use the value of the "job-name" attribute to | |
1380 | populate the Job object's "job-name" attribute. Whenever any | |
1381 | client queries the Job object's "job-name" attribute, the IPP | |
1382 | object returns the attribute as stored and uses the Natural | |
1383 | Language Override mechanism to specify the natural language, if | |
1384 | it is different from that reported in the "attributes-natural- | |
1385 | language" operation attribute of the response. The IPP object | |
1386 | MAY use the Natural Language Override mechanism redundantly, | |
1387 | i.e., use it even when the value is in the same natural language | |
1388 | as the value supplied in the "attributes-natural-language" | |
1389 | operation attribute of the response. | |
1390 | ||
1391 | An IPP object MUST NOT reject a request based on a supplied | |
1392 | natural language in an "attributes-natural-language" Operation | |
1393 | attribute or in any attribute that uses the Natural Language | |
1394 | Override. | |
1395 | ||
1396 | See the 'naturalLanguage' attribute syntax description in | |
1397 | section 4.1.8 for the syntax and semantic interpretation of the | |
1398 | values of this attribute and for example values. | |
1399 | ||
1400 | ||
1401 | ||
1402 | deBry, et al. Experimental [Page 25] | |
1403 | \f | |
1404 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1405 | ||
1406 | ||
1407 | Clients SHOULD NOT supply 'text' or 'name' attributes that use an | |
1408 | illegal combination of natural language and charset. For example, | |
1409 | suppose a Printer object supports charsets 'utf-8', 'iso-8859-1', and | |
1410 | 'iso-8859-7'. Suppose also, that it supports natural languages 'en' | |
1411 | (English), 'fr' (French), and 'el' (Greek). Although the Printer | |
1412 | object supports the charset 'iso-8859-1' and natural language 'el', | |
1413 | it probably does not support the combination of Greek text strings | |
1414 | using the 'iso-8859-1' charset. The Printer object handles this | |
1415 | apparent incompatibility differently depending on the context in | |
1416 | which it occurs: | |
1417 | ||
1418 | - In a create request: If the client supplies a text or name | |
1419 | attribute (for example, the "job-name" operation attribute) that | |
1420 | uses an apparently incompatible combination, it is a client | |
1421 | choice that does not affect the Printer object or its correct | |
1422 | operation. Therefore, the Printer object simply accepts the | |
1423 | client supplied value, stores it with the Job object, and | |
1424 | responds back with the same combination whenever the client (or | |
1425 | any client) queries for that attribute. | |
1426 | - In a query-type operation, like Get-Printer-Attributes: If the | |
1427 | client requests an apparently incompatible combination, the | |
1428 | Printer object responds (as described in section 3.1.4.2) using | |
1429 | the Printer's configured natural language rather than the natural | |
1430 | language requested by the client. | |
1431 | ||
1432 | In either case, the Printer object does not reject the request | |
1433 | because of the apparent incompatibility. The potential incompatible | |
1434 | combination of charset and natural language can occur either at the | |
1435 | global operation level or at the Natural Language Override | |
1436 | attribute-by-attribute level. In addition, since the response always | |
1437 | includes explicit charset and natural language information, there is | |
1438 | never any question or ambiguity in how the client interprets the | |
1439 | response. | |
1440 | ||
1441 | 3.1.4.2 Response Operation Attributes | |
1442 | ||
1443 | The Printer object MUST supply and the client MUST support the | |
1444 | following REQUIRED operation attributes in every IPP/1.0 operation | |
1445 | response: | |
1446 | ||
1447 | "attributes-charset" (charset): | |
1448 | This operation attribute identifies the charset used by any ' | |
1449 | text' and 'name' attributes that the Printer object is returning | |
1450 | in this response. The value in this response MUST be the same | |
1451 | value as the "attributes-charset" operation attribute supplied | |
1452 | by the client in the request. If this is not possible | |
1453 | ||
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | deBry, et al. Experimental [Page 26] | |
1459 | \f | |
1460 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1461 | ||
1462 | ||
1463 | (i.e., the charset requested is not supported), the request | |
1464 | would have been rejected. See "attributes-charset" described in | |
1465 | Section 3.1.4.1 above. | |
1466 | ||
1467 | If the Printer object supports more than just the 'utf-8' | |
1468 | charset, the Printer object MUST be able to code convert between | |
1469 | each of the charsets supported on a highest fidelity possible | |
1470 | basis in order to return the 'text' and 'name' attributes in the | |
1471 | charset requested by the client. However, some information loss | |
1472 | MAY occur during the charset conversion depending on the | |
1473 | charsets involved. For example, the Printer object may convert | |
1474 | from a UTF-8 'a' to a US-ASCII 'a' (with no loss of | |
1475 | information), from an ISO Latin 1 CAPITAL LETTER A WITH ACUTE | |
1476 | ACCENT to US-ASCII 'A' (losing the accent), or from a UTF-8 | |
1477 | Japanese Kanji character to some ISO Latin 1 error character | |
1478 | indication such as '?', decimal code equivalent, or to the | |
1479 | absence of a character, depending on implementation. | |
1480 | ||
1481 | Note: Whether an implementation that supports more than one | |
1482 | charset stores the data in the charset supplied by the client or | |
1483 | code converts to one of the other supported charsets, depends on | |
1484 | implementation. The strategy should try to minimize loss of | |
1485 | information during code conversion. On each response, such an | |
1486 | implementation converts from its internal charset to that | |
1487 | requested. | |
1488 | ||
1489 | "attributes-natural-language" (naturalLanguage): | |
1490 | This operation attribute identifies the natural language used by | |
1491 | any 'text' and 'name' attributes that the IPP object is | |
1492 | returning in this response. Unlike the "attributes-charset" | |
1493 | operation attribute, the IPP object NEED NOT return the same | |
1494 | value as that supplied by the client in the request. The IPP | |
1495 | object MAY return the natural language of the Job object or the | |
1496 | Printer's configured natural language as identified by the | |
1497 | Printer object's "natural-language-configured" attribute, rather | |
1498 | than the natural language supplied by the client. For any ' | |
1499 | text' or 'name' attribute or status message in the response that | |
1500 | is in a different natural language than the value returned in | |
1501 | the "attributes-natural-language" operation attribute, the IPP | |
1502 | object MUST use the Natural Language Override mechanism (see | |
1503 | sections 4.1.1.2 and 4.1.2.2) on each attribute value returned. | |
1504 | The IPP object MAY use the Natural Language Override mechanism | |
1505 | redundantly, i.e., use it even when the value is in the same | |
1506 | natural language as the value supplied in the "attributes- | |
1507 | natural-language" operation attribute of the response. | |
1508 | ||
1509 | ||
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | deBry, et al. Experimental [Page 27] | |
1515 | \f | |
1516 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1517 | ||
1518 | ||
1519 | 3.1.5 Operation Targets | |
1520 | ||
1521 | All IPP operations are directed at IPP objects. For Printer | |
1522 | operations, the operation is always directed at a Printer object | |
1523 | using one of its URIs (i.e., one of the values in the Printer | |
1524 | object's "printer-uri-supported" attribute). Even if the Printer | |
1525 | object supports more than one URI, the client supplies only one URI | |
1526 | as the target of the operation. The client identifies the target | |
1527 | object by supplying the correct URI in the "printer-uri (uri)" | |
1528 | operation attribute. | |
1529 | ||
1530 | For Job operations, the operation is directed at either: | |
1531 | ||
1532 | - The Job object itself using the Job object's URI. In this case, | |
1533 | the client identifies the target object by supplying the correct | |
1534 | URI in the "job-uri (uri)" operation attribute. | |
1535 | - The Printer object that created the Job object using both the | |
1536 | Printer objects URI and the Job object's Job ID. Since the | |
1537 | Printer object that created the Job object generated the Job ID, | |
1538 | it MUST be able to correctly associate the client supplied Job ID | |
1539 | with the correct Job object. The client supplies the Printer | |
1540 | object's URI in the "printer-uri (uri)" operation attribute and | |
1541 | the Job object's Job ID in the "job-id (integer(1:MAX))" | |
1542 | operation attribute. | |
1543 | ||
1544 | If the operation is directed at the Job object directly using the Job | |
1545 | object's URI, the client MUST NOT include the redundant "job-id" | |
1546 | operation attribute. | |
1547 | ||
1548 | The operation target attributes are REQUIRED operation attributes | |
1549 | that MUST be included in every operation request. Like the charset | |
1550 | and natural language attributes (see section 3.1.4), the operation | |
1551 | target attributes are specially ordered operation attributes. In all | |
1552 | cases, the operation target attributes immediately follow the | |
1553 | "attributes-charset" and "attributes-natural-language" attributes | |
1554 | within the operation attribute group, however the specific ordering | |
1555 | rules are: | |
1556 | ||
1557 | - In the case where there is only one operation target attribute | |
1558 | (i.e., either only the "printer-uri" attribute or only the "job- | |
1559 | uri" attribute), that attribute MUST be the third attribute in | |
1560 | the operation attributes group. | |
1561 | - In the case where Job operations use two operation target | |
1562 | attributes (i.e., the "printer-uri" and "job-id" attributes), the | |
1563 | "printer-uri" attribute MUST be the third attribute and the | |
1564 | "job-id" attribute MUST be the fourth attribute. | |
1565 | ||
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | deBry, et al. Experimental [Page 28] | |
1571 | \f | |
1572 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1573 | ||
1574 | ||
1575 | In all cases, the target URIs contained within the body of IPP | |
1576 | operation requests and responses must be in absolute format rather | |
1577 | than relative format (a relative URL identifies a resource with the | |
1578 | scope of the HTTP server, but does not include scheme, host or port). | |
1579 | ||
1580 | The following rules apply to the use of port numbers in URIs that | |
1581 | identify IPP objects: | |
1582 | ||
1583 | 1. If the URI scheme allows the port number to be explicitly | |
1584 | included in the URI string, and a port number is specified | |
1585 | within the URI, then that port number MUST be used by the client | |
1586 | to contact the IPP object. | |
1587 | ||
1588 | 2. If the URI scheme allows the port number to be explicitly | |
1589 | included in the URI string, and a port number is not specified | |
1590 | within the URI, then default port number implied by that URI | |
1591 | scheme MUST be used by the client to contact the IPP object. | |
1592 | ||
1593 | 3. If the URI scheme does not allow an explicit port number to be | |
1594 | specified within the URI, then the default port number implied | |
1595 | by that URI MUST be used by the client to contact the IPP | |
1596 | object. | |
1597 | ||
1598 | Note: The IPP encoding and transport document [RFC2565] shows a | |
1599 | mapping of IPP onto HTTP/1.1 and defines a new default port number | |
1600 | for using IPP over HTTP/1.1. | |
1601 | ||
1602 | 3.1.6 Operation Status Codes and Messages | |
1603 | ||
1604 | Every operation response includes a REQUIRED "status-code" parameter | |
1605 | and an OPTIONAL "status-message" operation attribute. The "status- | |
1606 | code" provides information on the processing of a request. A | |
1607 | "status-message" attribute provides a short textual description of | |
1608 | the status of the operation. The status code is intended for use by | |
1609 | automata, and the status message is intended for the human end user. | |
1610 | If a response does include a "status-message" attribute, an IPP | |
1611 | client NEED NOT examine or display the message, however it SHOULD do | |
1612 | so in some implementation specific manner. | |
1613 | ||
1614 | The "status-code" value is a numeric value that has semantic meaning. | |
1615 | The "status-code" syntax is similar to a "type2 enum" (see section | |
1616 | 4.1 on "Attribute Syntaxes") except that values can range only from | |
1617 | 0x0000 to 0x7FFF. Section 13 describes the status codes, assigns the | |
1618 | numeric values, and suggests a corresponding status message for each | |
1619 | status code. The "status-message" attribute's syntax is "text(255)". | |
1620 | A client implementation of IPP SHOULD convert status code values into | |
1621 | any localized message that has semantic meaning to the end user. | |
1622 | ||
1623 | ||
1624 | ||
1625 | ||
1626 | deBry, et al. Experimental [Page 29] | |
1627 | \f | |
1628 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1629 | ||
1630 | ||
1631 | If the Printer object supports the "status-message" operation | |
1632 | attribute, the Printer object MUST be able to generate this message | |
1633 | in any of the natural languages identified by the Printer object's | |
1634 | "generated-natural-language-supported" attribute (see the | |
1635 | "attributes-natural-language" operation attribute specified in | |
1636 | section 3.1.4.1). As described in section 3.1.4.1 for any returned ' | |
1637 | text' attribute, if there is a choice for generating this message, | |
1638 | the Printer object uses the natural language indicated by the value | |
1639 | of the "attributes-natural-language" in the client request if | |
1640 | supported, otherwise the Printer object uses the value in the Printer | |
1641 | object's own "natural-language-configured" attribute. If the Printer | |
1642 | object supports the "status-message" operation attribute, it SHOULD | |
1643 | use the REQUIRED 'utf-8' charset to return a status message for the | |
1644 | following error status codes (see section 13): 'client-error-bad- | |
1645 | request', 'client-error-charset-not-supported', 'server-error- | |
1646 | internal-error', 'server-error-operation-not-supported', and ' | |
1647 | server-error-version-not-supported'. In this case, it MUST set the | |
1648 | value of the "attributes-charset" operation attribute to 'utf-8' in | |
1649 | the error response. | |
1650 | ||
1651 | 3.1.7 Versions | |
1652 | ||
1653 | Each operation request and response carries with it a "version- | |
1654 | number" parameter. Each value of the "version-number" is in the form | |
1655 | "X.Y" where X is the major version number and Y is the minor version | |
1656 | number. By including a version number in the client request, it | |
1657 | allows the client to identify which version of IPP it is interested | |
1658 | in using. If the IPP object does not support that version, the | |
1659 | object responds with a status code of 'server-error-version-not- | |
1660 | supported' along with the closest version number that is supported | |
1661 | (see section 13.1.5.4). | |
1662 | ||
1663 | There is no version negotiation per se. However, if after receiving | |
1664 | a 'server-error-version-not-supported' status code from an IPP | |
1665 | object, there is nothing that prevents a client from trying again | |
1666 | with a different version number. In order to conform to IPP/1.0, an | |
1667 | implementation MUST support at least version '1.0'. | |
1668 | ||
1669 | There is only one notion of "version number" that covers both IPP | |
1670 | Model and IPP Protocol changes. Thus the version number MUST change | |
1671 | when introducing a new version of the Model and Semantics document | |
1672 | [RFC2566] or a new version of the Encoding and Transport document | |
1673 | [RFC2565]. | |
1674 | ||
1675 | Changes to the major version number indicate structural or syntactic | |
1676 | changes that make it impossible for older version of IPP clients and | |
1677 | Printer objects to correctly parse and process the new or changed | |
1678 | attributes, operations and responses. If the major version number | |
1679 | ||
1680 | ||
1681 | ||
1682 | deBry, et al. Experimental [Page 30] | |
1683 | \f | |
1684 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1685 | ||
1686 | ||
1687 | changes, the minor version numbers is set to zero. As an example, | |
1688 | adding the "ipp-attribute-fidelity" attribute (if it had not been | |
1689 | part of version '1.0'), would have required a change to the major | |
1690 | version number. Items that might affect the changing of the major | |
1691 | version number include any changes to the Model and Semantics | |
1692 | document [RFC2566] or the Encoding and Transport [RFC2565] itself, | |
1693 | such as: | |
1694 | ||
1695 | - reordering of ordered attributes or attribute sets | |
1696 | - changes to the syntax of existing attributes | |
1697 | - changing Operation or Job Template attributes from OPTIONAL to | |
1698 | REQUIRED and vice versa | |
1699 | - adding REQUIRED (for an IPP object to support) operation | |
1700 | attributes | |
1701 | - adding REQUIRED (for an IPP object to support) operation | |
1702 | attribute groups | |
1703 | - adding values to existing operation attributes | |
1704 | - adding REQUIRED operations | |
1705 | ||
1706 | Changes to the minor version number indicate the addition of new | |
1707 | features, attributes and attribute values that may not be understood | |
1708 | by all IPP objects, but which can be ignored if not understood. | |
1709 | Items that might affect the changing of the minor version number | |
1710 | include any changes to the model objects and attributes but not the | |
1711 | encoding and transport rules [RFC2565] (except adding attribute | |
1712 | syntaxes). Examples of such changes are: | |
1713 | ||
1714 | - grouping all extensions not included in a previous version into | |
1715 | a new version | |
1716 | - adding new attribute values | |
1717 | - adding new object attributes | |
1718 | - adding OPTIONAL (for an IPP object to support) operation | |
1719 | attributes (i.e., those attributes that an IPP object can ignore | |
1720 | without confusing clients) | |
1721 | - adding OPTIONAL (for an IPP object to support) operation | |
1722 | attribute groups (i.e., those attributes that an IPP object can | |
1723 | ignore without confusing clients) | |
1724 | - adding new attribute syntaxes | |
1725 | - adding OPTIONAL operations | |
1726 | - changing Job Description attributes or Printer Description | |
1727 | attributes from OPTIONAL to REQUIRED or vice versa. | |
1728 | ||
1729 | The encoding of the "operation-id", the "version-number", the | |
1730 | "status-code", and the "request-id" MUST NOT change over any version | |
1731 | number (either major or minor). This rule guarantees that all future | |
1732 | versions will be backwards compatible with all previous versions (at | |
1733 | least for checking the "operation-id", the "version-number", and the | |
1734 | "request-id"). In addition, any protocol elements (attributes, error | |
1735 | ||
1736 | ||
1737 | ||
1738 | deBry, et al. Experimental [Page 31] | |
1739 | \f | |
1740 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1741 | ||
1742 | ||
1743 | codes, tags, etc.) that are not carried forward from one version to | |
1744 | the next are deprecated so that they can never be reused with new | |
1745 | semantics. | |
1746 | ||
1747 | Implementations that support a certain major version NEED NOT support | |
1748 | ALL previous versions. As each new major version is defined (through | |
1749 | the release of a new specification), that major version will specify | |
1750 | which previous major versions MUST be supported in compliant | |
1751 | implementations. | |
1752 | ||
1753 | 3.1.8 Job Creation Operations | |
1754 | ||
1755 | In order to "submit a print job" and create a new Job object, a | |
1756 | client issues a create request. A create request is any one of | |
1757 | following three operation requests: | |
1758 | ||
1759 | - The Print-Job Request: A client that wants to submit a print job | |
1760 | with only a single document uses the Print-Job operation. The | |
1761 | operation allows for the client to "push" the document data to | |
1762 | the Printer object by including the document data in the request | |
1763 | itself. | |
1764 | ||
1765 | - The Print-URI Request: A client that wants to submit a print job | |
1766 | with only a single document (where the Printer object "pulls" the | |
1767 | document data instead of the client "pushing" the data to the | |
1768 | Printer object) uses the Print-URI operation. In this case, the | |
1769 | client includes in the request only a URI reference to the | |
1770 | document data (not the document data itself). | |
1771 | ||
1772 | - The Create-Job Request: A client that wants to submit a print job | |
1773 | with multiple documents uses the Create-Job operation. This | |
1774 | operation is followed by an arbitrary number of Send-Document | |
1775 | and/or Send-URI operations (each creating another document for | |
1776 | the newly create Job object). The Send-Document operation | |
1777 | includes the document data in the request (the client "pushes" | |
1778 | the document data to the printer), and the Send-URI operation | |
1779 | includes only a URI reference to the document data in the request | |
1780 | (the Printer "pulls" the document data from the referenced | |
1781 | location). The last Send-Document or Send-URI request for a | |
1782 | given Job object includes a "last-document" operation attribute | |
1783 | set to 'true' indicating that this is the last request. | |
1784 | ||
1785 | Throughout this model specification, the term "create request" is | |
1786 | used to refer to any of these three operation requests. | |
1787 | ||
1788 | A Create-Job operation followed by only one Send-Document operation | |
1789 | is semantically equivalent to a Print-Job operation, however, for | |
1790 | performance reasons, the client SHOULD use the Print-Job operation | |
1791 | ||
1792 | ||
1793 | ||
1794 | deBry, et al. Experimental [Page 32] | |
1795 | \f | |
1796 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1797 | ||
1798 | ||
1799 | for all single document jobs. Also, Print-Job is a REQUIRED | |
1800 | operation (all implementations MUST support it) whereas Create-Job is | |
1801 | an OPTIONAL operation, hence some implementations might not support | |
1802 | it. | |
1803 | ||
1804 | Job submission time is the point in time when a client issues a | |
1805 | create request. The initial state of every Job object is the ' | |
1806 | pending' or 'pending-held' state. Later, the Printer object begins | |
1807 | processing the print job. At this point in time, the Job object's | |
1808 | state moves to 'processing'. This is known as job processing time. | |
1809 | There are validation checks that must be done at job submission time | |
1810 | and others that must be performed at job processing time. | |
1811 | ||
1812 | At job submission time and at the time a Validate-Job operation is | |
1813 | received, the Printer MUST do the following: | |
1814 | ||
1815 | 1. Process the client supplied attributes and either accept or | |
1816 | reject the request | |
1817 | 2. Validate the syntax of and support for the scheme of any client | |
1818 | supplied URI | |
1819 | ||
1820 | At job submission time the Printer object MUST validate whether or | |
1821 | not the supplied attributes, attribute syntaxes, and values are | |
1822 | supported by matching them with the Printer object's corresponding | |
1823 | "xxx-supported" attributes. See section 3.2.1.2 for details. [ipp- | |
1824 | iig] presents suggested steps for an IPP object to either accept or | |
1825 | reject any request and additional steps for processing create | |
1826 | requests. | |
1827 | ||
1828 | At job submission time the Printer object NEED NOT perform the | |
1829 | validation checks reserved for job processing time such as: | |
1830 | ||
1831 | 1. Validating the document data | |
1832 | 2. Validating the actual contents of any client supplied URI | |
1833 | (resolve the reference and follow the link to the document data) | |
1834 | ||
1835 | At job submission time, these additional job processing time | |
1836 | validation checks are essentially useless, since they require | |
1837 | actually parsing and interpreting the document data, are not | |
1838 | guaranteed to be 100% accurate, and MUST be done, yet again, at job | |
1839 | processing time. Also, in the case of a URI, checking for | |
1840 | availability at job submission time does not guarantee availability | |
1841 | at job processing time. In addition, at job processing time, the | |
1842 | Printer object might discover any of the following conditions that | |
1843 | were not detectable at job submission time: | |
1844 | ||
1845 | - runtime errors in the document data, | |
1846 | - nested document data that is in an unsupported format, | |
1847 | ||
1848 | ||
1849 | ||
1850 | deBry, et al. Experimental [Page 33] | |
1851 | \f | |
1852 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1853 | ||
1854 | ||
1855 | - the URI reference is no longer valid (i.e., the server hosting | |
1856 | the document might be down), or | |
1857 | - any other job processing error | |
1858 | ||
1859 | At job processing time, since the Printer object has already | |
1860 | responded with a successful status code in the response to the create | |
1861 | request, if the Printer object detects an error, the Printer object | |
1862 | is unable to inform the end user of the error with an operation | |
1863 | status code. In this case, the Printer, depending on the error, can | |
1864 | set the "job-state", "job-state-reasons", or "job-state-message" | |
1865 | attributes to the appropriate value(s) so that later queries can | |
1866 | report the correct job status. | |
1867 | ||
1868 | Note: Asynchronous notification of events is outside the scope of | |
1869 | IPP/1.0. | |
1870 | ||
1871 | 3.2 Printer Operations | |
1872 | ||
1873 | All Printer operations are directed at Printer objects. A client | |
1874 | MUST always supply the "printer-uri" operation attribute in order to | |
1875 | identify the correct target of the operation. | |
1876 | ||
1877 | 3.2.1 Print-Job Operation | |
1878 | ||
1879 | This REQUIRED operation allows a client to submit a print job with | |
1880 | only one document and supply the document data (rather than just a | |
1881 | reference to the data). See Section 15 for the suggested steps for | |
1882 | processing create operations and their Operation and Job Template | |
1883 | attributes. | |
1884 | ||
1885 | 3.2.1.1 Print-Job Request | |
1886 | ||
1887 | The following groups of attributes are supplied as part of the | |
1888 | Print-Job Request: | |
1889 | ||
1890 | Group 1: Operation Attributes | |
1891 | ||
1892 | Natural Language and Character Set: | |
1893 | The "attributes-charset" and "attributes-natural-language" | |
1894 | attributes as described in section 3.1.4.1. The Printer object | |
1895 | MUST copy these values to the corresponding Job Description | |
1896 | attributes described in sections 4.3.23 and 4.3.24. | |
1897 | ||
1898 | Target: | |
1899 | The "printer-uri" (uri) operation attribute which is the target | |
1900 | for this operation as described in section 3.1.5. | |
1901 | ||
1902 | ||
1903 | ||
1904 | ||
1905 | ||
1906 | deBry, et al. Experimental [Page 34] | |
1907 | \f | |
1908 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1909 | ||
1910 | ||
1911 | Requesting User Name: | |
1912 | The "requesting-user-name" (name(MAX)) attribute SHOULD be | |
1913 | supplied by the client as described in section 8.3. | |
1914 | ||
1915 | "job-name" (name(MAX)): | |
1916 | The client OPTIONALLY supplies this attribute. The Printer | |
1917 | object MUST support this attribute. It contains the client | |
1918 | supplied Job name. If this attribute is supplied by the client, | |
1919 | its value is used for the "job-name" attribute of the newly | |
1920 | created Job object. The client MAY automatically include any | |
1921 | information that will help the end-user distinguish amongst | |
1922 | his/her jobs, such as the name of the application program along | |
1923 | with information from the document, such as the document name, | |
1924 | document subject, or source file name. If this attribute is not | |
1925 | supplied by the client, the Printer generates a name to use in | |
1926 | the "job-name" attribute of the newly created Job object (see | |
1927 | Section 4.3.5). | |
1928 | ||
1929 | "ipp-attribute-fidelity" (boolean): | |
1930 | The client OPTIONALLY supplies this attribute. The Printer | |
1931 | object MUST support this attribute. The value 'true' indicates | |
1932 | that total fidelity to client supplied Job Template attributes | |
1933 | and values is required, else the Printer object MUST reject the | |
1934 | Print-Job request. The value 'false' indicates that a | |
1935 | reasonable attempt to print the Job object is acceptable and the | |
1936 | Printer object MUST accept the Print-job request. If not | |
1937 | supplied, the Printer object assumes the value is 'false'. All | |
1938 | Printer objects MUST support both types of job processing. See | |
1939 | section 15 for a full description of "ipp-attribute-fidelity" | |
1940 | and its relationship to other attributes, especially the Printer | |
1941 | object's "pdl-override-supported" attribute. | |
1942 | ||
1943 | "document-name" (name(MAX)): | |
1944 | The client OPTIONALLY supplies this attribute. The Printer | |
1945 | object MUST support this attribute. It contains the client | |
1946 | supplied document name. The document name MAY be different than | |
1947 | the Job name. Typically, the client software automatically | |
1948 | supplies the document name on behalf of the end user by using a | |
1949 | file name or an application generated name. If this attribute | |
1950 | is supplied, its value can be used in a manner defined by each | |
1951 | implementation. Examples include: printed along with the Job | |
1952 | (job start sheet, page adornments, etc.), used by accounting or | |
1953 | resource tracking management tools, or even stored along with | |
1954 | the document as a document level attribute. IPP/1.0 does not | |
1955 | support the concept of document level attributes. | |
1956 | ||
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | deBry, et al. Experimental [Page 35] | |
1963 | \f | |
1964 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
1965 | ||
1966 | ||
1967 | "document-format" (mimeMediaType) : | |
1968 | The client OPTIONALLY supplies this attribute. The Printer | |
1969 | object MUST support this attribute. The value of this attribute | |
1970 | identifies the format of the supplied document data. If the | |
1971 | client does not supply this attribute, the Printer object | |
1972 | assumes that the document data is in the format defined by the | |
1973 | Printer object's "document-format-default" attribute. If the | |
1974 | client supplies this attribute, but the value is not supported | |
1975 | by the Printer object, i.e., the value is not one of the values | |
1976 | of the Printer object's "document-format-supported" attribute, | |
1977 | the Printer object MUST reject the request and return the ' | |
1978 | client-error-document-format-not-supported' status code. | |
1979 | ||
1980 | "document-natural-language" (naturalLanguage): | |
1981 | The client OPTIONALLY supplies this attribute. The Printer | |
1982 | object OPTIONALLY supports this attribute. This attribute | |
1983 | specifies the natural language of the document for those | |
1984 | document-formats that require a specification of the natural | |
1985 | language in order to image the document unambiguously. There are | |
1986 | no particular values required for the Printer object to support. | |
1987 | ||
1988 | "compression" (type3 keyword) | |
1989 | The client OPTIONALLY supplies this attribute. The Printer | |
1990 | object OPTIONALLY supports this attribute and the "compression- | |
1991 | supported" attribute (see section 4.4.29). The client supplied | |
1992 | "compression" operation attribute identifies the compression | |
1993 | algorithm used on the document data. If the client omits this | |
1994 | attribute, the Printer object MUST assume that the data is not | |
1995 | compressed. If the client supplies the attribute and the | |
1996 | Printer object supports the attribute, the Printer object uses | |
1997 | the corresponding decompression algorithm on the document data. | |
1998 | If the client supplies this attribute, but the value is not | |
1999 | supported by the Printer object, i.e., the value is not one of | |
2000 | the values of the Printer object's "compression-supported" | |
2001 | attribute, the Printer object MUST copy the attribute and its | |
2002 | value to the Unsupported Attributes response group, reject the | |
2003 | request, and return the 'client-error-attributes-or-values-not- | |
2004 | supported' status code. | |
2005 | ||
2006 | "job-k-octets" (integer(0:MAX)) | |
2007 | The client OPTIONALLY supplies this attribute. The Printer | |
2008 | object OPTIONALLY supports this attribute and the "job-k- | |
2009 | octets-supported" attribute (see section 4.4.30). The client | |
2010 | supplied "job-k-octets" operation attribute identifies the total | |
2011 | size of the document(s) in K octets being submitted (see section | |
2012 | 4.3.17 for the complete semantics). If the client supplies the | |
2013 | ||
2014 | ||
2015 | ||
2016 | ||
2017 | ||
2018 | deBry, et al. Experimental [Page 36] | |
2019 | \f | |
2020 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2021 | ||
2022 | ||
2023 | attribute and the Printer object supports the attribute, the | |
2024 | value of the attribute is used to populate the Job object's | |
2025 | "job-k-octets" Job Description attribute. | |
2026 | ||
2027 | Note: For this attribute and the following two attributes | |
2028 | ("job-impressions", and "job-media-sheets"), if the client | |
2029 | supplies the attribute, but the Printer object does not support | |
2030 | the attribute, the Printer object ignores the client-supplied | |
2031 | value. If the client supplies the attribute and the Printer | |
2032 | supports the attribute, and the value is within the range of the | |
2033 | corresponding Printer object's "xxx-supported" attribute, the | |
2034 | Printer object MUST use the value to populate the Job object's | |
2035 | "xxx" attribute. If the client supplies the attribute and the | |
2036 | Printer supports the attribute, but the value is outside the | |
2037 | range of the corresponding Printer object's "xxx-supported" | |
2038 | attribute, the Printer object MUST copy the attribute and its | |
2039 | value to the Unsupported Attributes response group, reject the | |
2040 | request, and return the 'client-error-attributes-or-values-not- | |
2041 | supported' status code. If the client does not supply the | |
2042 | attribute, the Printer object MAY choose to populate the | |
2043 | corresponding Job object attribute depending on whether the | |
2044 | Printer object supports the attribute and is able to calculate | |
2045 | or discern the correct value. | |
2046 | ||
2047 | "job-impressions" (integer(0:MAX)) | |
2048 | The client OPTIONALLY supplies this attribute. The Printer | |
2049 | object OPTIONALLY supports this attribute and the "job- | |
2050 | impressions-supported" attribute (see section 4.4.31). The | |
2051 | client supplied "job-impressions" operation attribute identifies | |
2052 | the total size in number of impressions of the document(s) being | |
2053 | submitted (see section 4.3.18 for the complete semantics). | |
2054 | ||
2055 | See note under "job-k-octets". | |
2056 | ||
2057 | "job-media-sheets" (integer(0:MAX)) | |
2058 | The client OPTIONALLY supplies this attribute. The Printer | |
2059 | object OPTIONALLY supports this attribute and the "job-media- | |
2060 | sheets-supported" attribute (see section 4.4.32). The client | |
2061 | supplied "job-media-sheets" operation attribute identifies the | |
2062 | total number of media sheets to be produced for this job (see | |
2063 | section 4.3.19 for the complete semantics). | |
2064 | ||
2065 | See note under "job-k-octets". | |
2066 | ||
2067 | ||
2068 | ||
2069 | ||
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | deBry, et al. Experimental [Page 37] | |
2075 | \f | |
2076 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2077 | ||
2078 | ||
2079 | Group 2: Job Template Attributes | |
2080 | ||
2081 | The client OPTIONALLY supplies a set of Job Template attributes | |
2082 | as defined in section 4.2. If the client is not supplying any | |
2083 | Job Template attributes in the request, the client SHOULD omit | |
2084 | Group 2 rather than sending an empty group. However, a Printer | |
2085 | object MUST be able to accept an empty group. | |
2086 | ||
2087 | Group 3: Document Content | |
2088 | ||
2089 | The client MUST supply the document data to be processed. | |
2090 | ||
2091 | Note: In addition to the MANDATORY parameters required for every | |
2092 | operation request, the simplest Print-Job Request consists of just | |
2093 | the "attributes-charset" and "attributes-natural-language" operation | |
2094 | attributes; the "printer-uri" target operation attribute; the | |
2095 | Document Content and nothing else. In this simple case, the Printer | |
2096 | object: | |
2097 | ||
2098 | - creates a new Job object (the Job object contains a single | |
2099 | document), | |
2100 | - stores a generated Job name in the "job-name" attribute in the | |
2101 | natural language and charset requested (see Section 3.1.4.1) (if | |
2102 | those are supported, otherwise using the Printer object's default | |
2103 | natural language and charset), and | |
2104 | - at job processing time, uses its corresponding default value | |
2105 | attributes for the supported Job Template attributes that were | |
2106 | not supplied by the client as IPP attribute or embedded | |
2107 | instructions in the document data. | |
2108 | ||
2109 | 3.2.1.2 Print-Job Response | |
2110 | ||
2111 | The Printer object MUST return to the client the following sets | |
2112 | of attributes as part of the Print-Job Response: | |
2113 | ||
2114 | Group 1: Operation Attributes | |
2115 | ||
2116 | Status Message: | |
2117 | In addition to the REQUIRED status code returned in every | |
2118 | response, the response OPTIONALLY includes a "status-message" | |
2119 | (text) operation attribute as described in sections 14 and | |
2120 | 3.1.6. If the client supplies unsupported or conflicting Job | |
2121 | Template attributes or values, the Printer object MUST reject or | |
2122 | accept the Print-Job request depending on the whether the client | |
2123 | supplied a 'true' or 'false' value for the "ipp-attribute- | |
2124 | fidelity" operation attribute. See the Implementer's Guide | |
2125 | [ipp-iig] for a complete description of the suggested steps for | |
2126 | processing a create request. | |
2127 | ||
2128 | ||
2129 | ||
2130 | deBry, et al. Experimental [Page 38] | |
2131 | \f | |
2132 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2133 | ||
2134 | ||
2135 | Natural Language and Character Set: | |
2136 | The "attributes-charset" and "attributes-natural-language" | |
2137 | attributes as described in section 3.1.4.2. | |
2138 | ||
2139 | Group 2: Unsupported Attributes | |
2140 | ||
2141 | This is a set of Operation and Job Template attributes supplied | |
2142 | by the client (in the request) that are not supported by the | |
2143 | Printer object or that conflict with one another (see the | |
2144 | Implementer's Guide [ipp-iig]). If the Printer object is not | |
2145 | returning any Unsupported Attributes in the response, the | |
2146 | Printer object SHOULD omit Group 2 rather than sending an empty | |
2147 | group. However, a client MUST be able to accept an empty group. | |
2148 | ||
2149 | Unsupported attributes fall into three categories: | |
2150 | ||
2151 | 1. The Printer object does not support the supplied attribute | |
2152 | (no matter what the attribute syntax or value). | |
2153 | 2. The Printer object does support the attribute, but does not | |
2154 | support some or all of the particular attribute syntaxes or | |
2155 | values supplied by the client (i.e., the Printer object does | |
2156 | not have those attribute syntaxes or values in its | |
2157 | corresponding "xxx-supported" attribute). | |
2158 | 3. The Printer object does support the attributes and values | |
2159 | supplied, but the particular values are in conflict with one | |
2160 | another, because they violate a constraint, such as not being | |
2161 | able to staple transparencies. | |
2162 | ||
2163 | In the case of an unsupported attribute name, the Printer object | |
2164 | returns the client-supplied attribute with a substituted "out- | |
2165 | of-band" value of 'unsupported' indicating no support for the | |
2166 | attribute itself (see the beginning of section 4.1). | |
2167 | ||
2168 | In the case of a supported attribute with one or more | |
2169 | unsupported attribute syntaxes or values, the Printer object | |
2170 | simply returns the client-supplied attribute with the | |
2171 | unsupported attribute syntaxes or values as supplied by the | |
2172 | client. This indicates support for the attribute, but no | |
2173 | support for that particular attribute syntax or value. If the | |
2174 | client supplies a multi-valued attribute with more than one | |
2175 | value and the Printer object supports the attribute but only | |
2176 | supports a subset of the client-supplied attribute syntaxes or | |
2177 | values, the Printer object MUST return only those attribute | |
2178 | syntaxes or values that are unsupported. | |
2179 | ||
2180 | In the case of two (or more) supported attribute values that are | |
2181 | in conflict with one another (although each is supported | |
2182 | independently, the values conflict when requested together | |
2183 | ||
2184 | ||
2185 | ||
2186 | deBry, et al. Experimental [Page 39] | |
2187 | \f | |
2188 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2189 | ||
2190 | ||
2191 | within the same job), the Printer object MUST return all the | |
2192 | values that it ignores or substitutes to resolve the conflict, | |
2193 | but not any of the values that it is still using. The choice | |
2194 | for exactly how to resolve the conflict is implementation | |
2195 | dependent. See The Implementer's Guide [ipp-iig] for an | |
2196 | example. | |
2197 | ||
2198 | In these three cases, the value of the "ipp-attribute-fidelity" | |
2199 | supplied by the client does not affect what the Printer object | |
2200 | returns. The value of "ipp-attribute-fidelity" only affects | |
2201 | whether the Print-Job operation is accepted or rejected. If the | |
2202 | job is accepted, the client may query the job using the Get- | |
2203 | Job-Attributes operation requesting the unsupported attributes | |
2204 | that were returned in the create response to see which | |
2205 | attributes were ignored (not stored on the Job object) and which | |
2206 | attributes were stored with other (substituted) values. | |
2207 | ||
2208 | Group 3: Job Object Attributes | |
2209 | ||
2210 | "job-uri" (uri): | |
2211 | The Printer object MUST return the Job object's URI by returning | |
2212 | the contents of the REQUIRED "job-uri" Job object attribute. | |
2213 | The client uses the Job object's URI when directing operations | |
2214 | at the Job object. The Printer object always uses its | |
2215 | configured security policy when creating the new URI. However, | |
2216 | if the Printer object supports more than one URI, the Printer | |
2217 | object also uses information about which URI was used in the | |
2218 | Print-Job Request to generated the new URI so that the new URI | |
2219 | references the correct access channel. In other words, if the | |
2220 | Print-Job Request comes in over a secure channel, the Printer | |
2221 | object MUST generate a Job URI that uses the secure channel as | |
2222 | well. | |
2223 | ||
2224 | "job-id" (integer(1:MAX)): | |
2225 | The Printer object MUST return the Job object's Job ID by | |
2226 | returning the REQUIRED "job-id" Job object attribute. The | |
2227 | client uses this "job-id" attribute in conjunction with the | |
2228 | "printer-uri" attribute used in the Print-Job Request when | |
2229 | directing Job operations at the Printer object. | |
2230 | ||
2231 | "job-state": | |
2232 | The Printer object MUST return the Job object's REQUIRED "job- | |
2233 | state" attribute. The value of this attribute (along with the | |
2234 | value of the next attribute "job-state-reasons") is taken from a | |
2235 | "snapshot" of the new Job object at some meaningful point in | |
2236 | time (implementation defined) between when the Printer object | |
2237 | receives the Print-Job Request and when the Printer object | |
2238 | returns the response. | |
2239 | ||
2240 | ||
2241 | ||
2242 | deBry, et al. Experimental [Page 40] | |
2243 | \f | |
2244 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2245 | ||
2246 | ||
2247 | "job-state-reasons": | |
2248 | The Printer object OPTIONALLY returns the Job object's OPTIONAL | |
2249 | "job-state-reasons" attribute. If the Printer object supports | |
2250 | this attribute then it MUST be returned in the response. If | |
2251 | this attribute is not returned in the response, the client can | |
2252 | assume that the "job-state-reasons" attribute is not supported | |
2253 | and will not be returned in a subsequent Job object query. | |
2254 | ||
2255 | "job-state-message": | |
2256 | The Printer object OPTIONALLY returns the Job object's OPTIONAL | |
2257 | "job-state-message" attribute. If the Printer object supports | |
2258 | this attribute then it MUST be returned in the response. If | |
2259 | this attribute is not returned in the response, the client can | |
2260 | assume that the "job-state-message" attribute is not supported | |
2261 | and will not be returned in a subsequent Job object query. | |
2262 | ||
2263 | "number-of-intervening-jobs": | |
2264 | The Printer object OPTIONALLY returns the Job object's OPTIONAL | |
2265 | "number-of-intervening-jobs" attribute. If the Printer object | |
2266 | supports this attribute then it MUST be returned in the | |
2267 | response. If this attribute is not returned in the response, | |
2268 | the client can assume that the "number-of-intervening-jobs" | |
2269 | attribute is not supported and will not be returned in a | |
2270 | subsequent Job object query. | |
2271 | ||
2272 | Note: Since any printer state information which affects a job's | |
2273 | state is reflected in the "job-state" and "job-state-reasons" | |
2274 | attributes, it is sufficient to return only these attributes and | |
2275 | no specific printer status attributes. | |
2276 | ||
2277 | Note: In addition to the MANDATORY parameters required for every | |
2278 | operation response, the simplest response consists of the just the | |
2279 | "attributes-charset" and "attributes-natural-language" operation | |
2280 | attributes and the "job-uri", "job-id", and "job-state" Job Object | |
2281 | Attributes. In this simplest case, the status code is "successful- | |
2282 | ok" and there is no "status-message" operation attribute. | |
2283 | ||
2284 | 3.2.2 Print-URI Operation | |
2285 | ||
2286 | This OPTIONAL operation is identical to the Print-Job operation | |
2287 | (section 3.2.1) except that a client supplies a URI reference to the | |
2288 | document data using the "document-uri" (uri) operation attribute (in | |
2289 | Group 1) rather than including the document data itself. Before | |
2290 | returning the response, the Printer MUST validate that the Printer | |
2291 | supports the retrieval method (e.g., http, ftp, etc.) implied by the | |
2292 | URI, and MUST check for valid URI syntax. If the client-supplied URI | |
2293 | scheme is not supported, i.e. the value is not in the Printer | |
2294 | object's "referenced-uri-scheme-supported" attribute, the Printer | |
2295 | ||
2296 | ||
2297 | ||
2298 | deBry, et al. Experimental [Page 41] | |
2299 | \f | |
2300 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2301 | ||
2302 | ||
2303 | object MUST reject the request and return the 'client-error-uri- | |
2304 | scheme-not-supported' status code. See The Implementer's Guide | |
2305 | [ipp-iig] for suggested additional checks. The Printer NEED NOT | |
2306 | follow the reference and validate the contents of the reference. | |
2307 | ||
2308 | If the Printer object supports this operation, it MUST support the | |
2309 | "reference-uri-schemes-supported" Printer attribute (see section | |
2310 | 4.4.24). | |
2311 | ||
2312 | It is up to the IPP object to interpret the URI and subsequently | |
2313 | "pull" the document from the source referenced by the URI string. | |
2314 | ||
2315 | 3.2.3 Validate-Job Operation | |
2316 | ||
2317 | This REQUIRED operation is similar to the Print-Job operation | |
2318 | (section 3.2.1) except that a client supplies no document data and | |
2319 | the Printer allocates no resources (i.e., it does not create a new | |
2320 | Job object). This operation is used only to verify capabilities of a | |
2321 | printer object against whatever attributes are supplied by the client | |
2322 | in the Validate-Job request. By using the Validate-Job operation a | |
2323 | client can validate that an identical Print-Job operation (with the | |
2324 | document data) would be accepted. The Validate-Job operation also | |
2325 | performs the same security negotiation as the Print-Job operation | |
2326 | (see section 8), so that a client can check that the client and | |
2327 | Printer object security requirements can be met before performing a | |
2328 | Print-Job operation. | |
2329 | ||
2330 | Note: The Validate-Job operation does not accept a "document-uri" | |
2331 | attribute in order to allow a client to check that the same Print-URI | |
2332 | operation will be accepted, since the client doesn't send the data | |
2333 | with the Print-URI operation. The client SHOULD just issue the | |
2334 | Print-URI request. | |
2335 | ||
2336 | The Printer object returns the same status codes, Operation | |
2337 | Attributes (Group 1) and Unsupported Attributes (Group 2) as the | |
2338 | Print-Job operation. However, no Job Object Attributes (Group 3) are | |
2339 | returned, since no Job object is created. | |
2340 | ||
2341 | 3.2.4 Create-Job Operation | |
2342 | ||
2343 | This OPTIONAL operation is similar to the Print-Job operation | |
2344 | (section 3.2.1) except that in the Create-Job request, a client does | |
2345 | not supply document data or any reference to document data. Also, | |
2346 | the client does not supply any of the "document-name", "document- | |
2347 | format", "compression", or "document-natural-language" operation | |
2348 | attributes. This operation is followed by one or more Send-Document | |
2349 | or Send-URI operations. In each of those operation requests, the | |
2350 | ||
2351 | ||
2352 | ||
2353 | ||
2354 | deBry, et al. Experimental [Page 42] | |
2355 | \f | |
2356 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2357 | ||
2358 | ||
2359 | client OPTIONALLY supplies the "document-name", "document-format", | |
2360 | and "document-natural-language" attributes for each document in the | |
2361 | multi-document Job object. | |
2362 | ||
2363 | If a Printer object supports the Create-Job operation, it MUST also | |
2364 | support the Send-Document operation and also MAY support the Send-URI | |
2365 | operation. | |
2366 | ||
2367 | If the Printer object supports this operation, it MUST support the | |
2368 | "multiple-operation-time-out" Printer attribute (see section 4.4.28). | |
2369 | ||
2370 | ||
2371 | 3.2.5 Get-Printer-Attributes Operation | |
2372 | ||
2373 | This REQUIRED operation allows a client to request the values of the | |
2374 | attributes of a Printer object. In the request, the client supplies | |
2375 | the set of Printer attribute names and/or attribute group names in | |
2376 | which the requester is interested. In the response, the Printer | |
2377 | object returns a corresponding attribute set with the appropriate | |
2378 | attribute values filled in. | |
2379 | ||
2380 | For Printer objects, the possible names of attribute groups are: | |
2381 | ||
2382 | - 'job-template': all of the Job Template attributes that apply to | |
2383 | a Printer object (the last two columns of the table in Section | |
2384 | 4.2). | |
2385 | - 'printer-description': the attributes specified in Section 4.4. | |
2386 | - 'all': the special group 'all' that includes all supported | |
2387 | attributes. | |
2388 | ||
2389 | Since a client MAY request specific attributes or named groups, there | |
2390 | is a potential that there is some overlap. For example, if a client | |
2391 | requests, 'printer-name' and 'all', the client is actually requesting | |
2392 | the "printer-name" attribute twice: once by naming it explicitly, and | |
2393 | once by inclusion in the 'all' group. In such cases, the Printer | |
2394 | object NEED NOT return each attribute only once in the response even | |
2395 | if it is requested multiple times. The client SHOULD NOT request the | |
2396 | same attribute in multiple ways. | |
2397 | ||
2398 | It is NOT REQUIRED that a Printer object support all attributes | |
2399 | belonging to a group (since some attributes are OPTIONAL). However, | |
2400 | it is REQUIRED that each Printer object support all group names. | |
2401 | ||
2402 | ||
2403 | ||
2404 | ||
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | deBry, et al. Experimental [Page 43] | |
2411 | \f | |
2412 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2413 | ||
2414 | ||
2415 | 3.2.5.1 Get-Printer-Attributes Request | |
2416 | ||
2417 | The following sets of attributes are part of the Get-Printer- | |
2418 | Attributes Request: | |
2419 | ||
2420 | Group 1: Operation Attributes | |
2421 | ||
2422 | Natural Language and Character Set: | |
2423 | attributes-charset" and "attributes-natural-language" butes as | |
2424 | described in section 3.1.4.1. | |
2425 | ||
2426 | Target: | |
2427 | The "printer-uri" (uri) operation attribute which is the target | |
2428 | for this operation as described in section 3.1.5. | |
2429 | ||
2430 | Requesting User Name: | |
2431 | The "requesting-user-name" (name(MAX)) attribute SHOULD be | |
2432 | supplied by the client as described in section 8.3. | |
2433 | ||
2434 | "requested-attributes" (1setOf keyword) : | |
2435 | The client OPTIONALLY supplies a set of attribute names and/or | |
2436 | attribute group names in whose values the requester is | |
2437 | interested. The Printer object MUST support this attribute. If | |
2438 | the client omits this attribute, the Printer MUST respond as if | |
2439 | this attribute had been supplied with a value of 'all'. | |
2440 | ||
2441 | "document-format" (mimeMediaType) : | |
2442 | The client OPTIONALLY supplies this attribute. The Printer | |
2443 | object MUST support this attribute. This attribute is useful | |
2444 | for a Printer object to determine the set of supported attribute | |
2445 | values that relate to the requested document format. The | |
2446 | Printer object MUST return the attributes and values that it | |
2447 | uses to validate a job on a create or Validate-Job operation in | |
2448 | which this document format is supplied. The Printer object | |
2449 | SHOULD return only (1) those attributes that are supported for | |
2450 | the specified format and (2) the attribute values that are | |
2451 | supported for the specified document format. By specifying the | |
2452 | document format, the client can get the Printer object to | |
2453 | eliminate the attributes and values that are not supported for a | |
2454 | specific document format. For example, a Printer object might | |
2455 | have multiple interpreters to support both ' | |
2456 | application/postscript' (for PostScript) and 'text/plain' (for | |
2457 | text) documents. However, for only one of those interpreters | |
2458 | might the Printer object be able to support "number-up" with | |
2459 | values of '1', '2', and '4'. For the other interpreter it might | |
2460 | be able to only support "number-up" with a value of '1'. Thus a | |
2461 | ||
2462 | ||
2463 | ||
2464 | ||
2465 | ||
2466 | deBry, et al. Experimental [Page 44] | |
2467 | \f | |
2468 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2469 | ||
2470 | ||
2471 | client can use the Get-Printer-Attributes operation to obtain | |
2472 | the attributes and values that will be used to accept/reject a | |
2473 | create job operation. | |
2474 | ||
2475 | If the Printer object does not distinguish between different | |
2476 | sets of supported values for each different document format when | |
2477 | validating jobs in the create and Validate-Job operations, it | |
2478 | MUST NOT distinguish between different document formats in the | |
2479 | Get-Printer-Attributes operation. If the Printer object does | |
2480 | distinguish between different sets of supported values for each | |
2481 | different document format specified by the client, this | |
2482 | specialization applies only to the following Printer object | |
2483 | attributes: | |
2484 | ||
2485 | - Printer attributes that are Job Template attributes ("xxx- | |
2486 | default" "xxx-supported", and "xxx-ready" in the Table in | |
2487 | Section 4.2), | |
2488 | - "pdl-override-supported", | |
2489 | - "compression-supported", | |
2490 | - "job-k-octets-supported", | |
2491 | - "job-impressions-supported, | |
2492 | - "job-media-sheets-supported" | |
2493 | - "printer-driver-installer", | |
2494 | - "color-supported", and | |
2495 | - "reference-uri-schemes-supported" | |
2496 | ||
2497 | The values of all other Printer object attributes (including | |
2498 | "document-format-supported") remain invariant with respect to | |
2499 | the client supplied document format (except for new Printer | |
2500 | description attribute as registered according to section 6.2). | |
2501 | ||
2502 | If the client omits this "document-format" operation attribute, | |
2503 | the Printer object MUST respond as if the attribute had been | |
2504 | supplied with the value of the Printer object's "document- | |
2505 | format-default" attribute. It is recommended that the client | |
2506 | always supply a value for "document-format", since the Printer | |
2507 | object's "document-format-default" may be 'application/octet- | |
2508 | stream', in which case the returned attributes and values are | |
2509 | for the union of the document formats that the Printer can | |
2510 | automatically sense. For more details, see the description of | |
2511 | the 'mimeMediaType' attribute syntax in section 4.1.9. | |
2512 | ||
2513 | If the client supplies a value for the "document-format" | |
2514 | Operation attribute that is not supported by the Printer, i.e., | |
2515 | is not among the values of the Printer object's "document- | |
2516 | format-supported" attribute, the Printer object MUST reject the | |
2517 | operation and return the 'client-error-document-format-not- | |
2518 | supported' status code. | |
2519 | ||
2520 | ||
2521 | ||
2522 | deBry, et al. Experimental [Page 45] | |
2523 | \f | |
2524 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2525 | ||
2526 | ||
2527 | 3.2.5.2 Get-Printer-Attributes Response | |
2528 | ||
2529 | The Printer object returns the following sets of attributes as part | |
2530 | of the Get-Printer-Attributes Response: | |
2531 | ||
2532 | Group 1: Operation Attributes | |
2533 | ||
2534 | Status Message: | |
2535 | In addition to the REQUIRED status code returned in every | |
2536 | response, the response OPTIONALLY includes a "status-message" | |
2537 | (text) operation attribute as described in section 3.1.6. | |
2538 | ||
2539 | Natural Language and Character Set: | |
2540 | The "attributes-charset" and "attributes-natural-language" | |
2541 | attributes as described in section 3.1.4.2. | |
2542 | ||
2543 | Group 2: Unsupported Attributes | |
2544 | ||
2545 | This is a set of Operation attributes supplied by the client (in | |
2546 | the request) that are not supported by the Printer object or | |
2547 | that conflict with one another (see sections 3.2.1.2 and 16). | |
2548 | The response NEED NOT contain the "requested-attributes" | |
2549 | operation attribute with any supplied values (attribute | |
2550 | keywords) that were requested by the client but are not | |
2551 | supported by the IPP object. If the Printer object is not | |
2552 | returning any Unsupported Attributes in the response, the | |
2553 | Printer object SHOULD omit Group 2 rather than sending an empty | |
2554 | group. However, a client MUST be able to accept an empty group. | |
2555 | ||
2556 | Group 3: Printer Object Attributes | |
2557 | ||
2558 | This is the set of requested attributes and their current | |
2559 | values. The Printer object ignores (does not respond with) any | |
2560 | requested attribute which is not supported. The Printer object | |
2561 | MAY respond with a subset of the supported attributes and | |
2562 | values, depending on the security policy in force. However, the | |
2563 | Printer object MUST respond with the 'unknown' value for any | |
2564 | supported attribute (including all REQUIRED attributes) for | |
2565 | which the Printer object does not know the value. Also the | |
2566 | Printer object MUST respond with the 'no-value' for any | |
2567 | supported attribute (including all REQUIRED attributes) for | |
2568 | which the system administrator has not configured a value. See | |
2569 | the description of the "out-of-band" values in the beginning of | |
2570 | Section 4.1. | |
2571 | ||
2572 | ||
2573 | ||
2574 | ||
2575 | ||
2576 | ||
2577 | ||
2578 | deBry, et al. Experimental [Page 46] | |
2579 | \f | |
2580 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2581 | ||
2582 | ||
2583 | 3.2.6 Get-Jobs Operation | |
2584 | ||
2585 | This REQUIRED operation allows a client to retrieve the list of Job | |
2586 | objects belonging to the target Printer object. The client may also | |
2587 | supply a list of Job attribute names and/or attribute group names. A | |
2588 | group of Job object attributes will be returned for each Job object | |
2589 | that is returned. | |
2590 | ||
2591 | This operation is similar to the Get-Job-Attributes operation, except | |
2592 | that this Get-Jobs operation returns attributes from possibly more | |
2593 | than one object (see the description of Job attribute group names in | |
2594 | section 3.3.4). | |
2595 | ||
2596 | 3.2.6.1 Get-Jobs Request | |
2597 | ||
2598 | The client submits the Get-Jobs request to a Printer object. | |
2599 | ||
2600 | The following groups of attributes are part of the Get-Jobs Request: | |
2601 | ||
2602 | Group 1: Operation Attributes | |
2603 | ||
2604 | Natural Language and Character Set: | |
2605 | The "attributes-charset" and "attributes-natural-language" | |
2606 | attributes as described in section 3.1.4.1. | |
2607 | ||
2608 | Target: | |
2609 | The "printer-uri" (uri) operation attribute which is the target | |
2610 | for this operation as described in section 3.1.5. | |
2611 | ||
2612 | Requesting User Name: | |
2613 | The "requesting-user-name" (name(MAX)) attribute SHOULD be | |
2614 | supplied by the client as described in section 8.3. | |
2615 | ||
2616 | "limit" (integer(1:MAX)): | |
2617 | The client OPTIONALLY supplies this attribute. The Printer | |
2618 | object MUST support this attribute. It is an integer value that | |
2619 | indicates a limit to the number of Job objects returned. The | |
2620 | limit is a "stateless limit" in that if the value supplied by | |
2621 | the client is 'N', then only the first 'N' jobs are returned in | |
2622 | the Get-Jobs Response. There is no mechanism to allow for the | |
2623 | next 'M' jobs after the first 'N' jobs. If the client does not | |
2624 | supply this attribute, the Printer object responds with all | |
2625 | applicable jobs. | |
2626 | ||
2627 | "requested-attributes" (1setOf keyword): | |
2628 | The client OPTIONALLY supplies this attribute. The Printer | |
2629 | object MUST support this attribute. It is a set of Job | |
2630 | attribute names and/or attribute groups names in whose values | |
2631 | ||
2632 | ||
2633 | ||
2634 | deBry, et al. Experimental [Page 47] | |
2635 | \f | |
2636 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2637 | ||
2638 | ||
2639 | the requester is interested. This set of attributes is returned | |
2640 | for each Job object that is returned. The allowed attribute | |
2641 | group names are the same as those defined in the Get-Job- | |
2642 | Attributes operation in section 3.3.4. If the client does not | |
2643 | supply this attribute, the Printer MUST respond as if the client | |
2644 | had supplied this attribute with two values: 'job-uri' and ' | |
2645 | job-id'. | |
2646 | ||
2647 | "which-jobs" (type2 keyword): | |
2648 | The client OPTIONALLY supplies this attribute. The Printer | |
2649 | object MUST support this attribute. It indicates which Job | |
2650 | objects MUST be returned by the Printer object. The values for | |
2651 | this attribute are: | |
2652 | ||
2653 | 'completed': This includes any Job object whose state is | |
2654 | 'completed', 'canceled', or 'aborted'. | |
2655 | 'not-completed': This includes any Job object whose state is ' | |
2656 | pending', 'processing', 'processing-stopped', or 'pending- | |
2657 | held'. | |
2658 | ||
2659 | A Printer object MUST support both values. However, if the | |
2660 | mentation does not keep jobs in the 'completed', 'canceled', ' | |
2661 | aborted' states, then it returns no jobs when the 'completed' | |
2662 | value is supplied. | |
2663 | ||
2664 | If a client supplies some other value, the Printer object MUST | |
2665 | copy the attribute and the unsupported value to the Unsupported | |
2666 | Attributes response group, reject the request, and return the ' | |
2667 | client-error-attributes-or-values-not-supported' status code. | |
2668 | ||
2669 | If the client does not supply this attribute, the Printer object | |
2670 | MUST respond as if the client had supplied the attribute with a | |
2671 | value of 'not-completed'. | |
2672 | ||
2673 | "my-jobs" (boolean): | |
2674 | The client OPTIONALLY supplies this attribute. The Printer | |
2675 | object MUST support this attribute. It indicates whether all | |
2676 | jobs or just the jobs submitted by the requesting user of this | |
2677 | request MUST be returned by the Printer object. If the client | |
2678 | does not supply this attribute, the Printer object MUST respond | |
2679 | as if the client had supplied the attribute with a value of ' | |
2680 | false', i.e., all jobs. The means for authenticating the | |
2681 | requesting user and matching the jobs is described in section 8. | |
2682 | ||
2683 | ||
2684 | ||
2685 | ||
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | deBry, et al. Experimental [Page 48] | |
2691 | \f | |
2692 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2693 | ||
2694 | ||
2695 | 3.2.6.2 Get-Jobs Response | |
2696 | ||
2697 | The Printer object returns all of the Job objects that match the | |
2698 | criteria as defined by the attribute values supplied by the client in | |
2699 | the request. It is possible that no Job objects are returned since | |
2700 | there may literally be no Job objects at the Printer, or there may be | |
2701 | no Job objects that match the criteria supplied by the client. If | |
2702 | the client requests any Job attributes at all, there is a set of Job | |
2703 | Object Attributes returned for each Job object. | |
2704 | ||
2705 | Group 1: Operation Attributes | |
2706 | ||
2707 | Status Message: | |
2708 | In addition to the REQUIRED status code returned in every | |
2709 | response, the response OPTIONALLY includes a "status-message" | |
2710 | (text) operation attribute as described in sections 14 and | |
2711 | 3.1.6. | |
2712 | ||
2713 | Natural Language and Character Set: | |
2714 | The "attributes-charset" and "attributes-natural-language" | |
2715 | attributes as described in section 3.1.4.2. | |
2716 | ||
2717 | Group 2: Unsupported Attributes | |
2718 | ||
2719 | This is a set of Operation attributes supplied by the client (in | |
2720 | the request) that are not supported by the Printer object or | |
2721 | that conflict with one another (see sections 3.2.1.2 and the | |
2722 | Implementer's Guide [ipp-iig]). The response NEED NOT contain | |
2723 | the "requested-attributes" operation attribute with any supplied | |
2724 | values (attribute keywords) that were requested by the client | |
2725 | but are not supported by the IPP object. If the Printer object | |
2726 | is not returning any Unsupported Attributes in the response, the | |
2727 | Printer object SHOULD omit Group 2 rather than sending an empty | |
2728 | group. However, a client MUST be able to accept an empty group. | |
2729 | ||
2730 | Groups 3 to N: Job Object Attributes | |
2731 | ||
2732 | The Printer object responds with one set of Job Object | |
2733 | Attributes for each returned Job object. The Printer object | |
2734 | ignores (does not respond with) any requested attribute or value | |
2735 | which is not supported or which is restricted by the security | |
2736 | policy in force, including whether the requesting user is the | |
2737 | user that submitted the job (job originating user) or not (see | |
2738 | section 8). However, the Printer object MUST respond with the ' | |
2739 | unknown' value for any supported attribute (including all | |
2740 | REQUIRED attributes) for which the Printer object does not know | |
2741 | ||
2742 | ||
2743 | ||
2744 | ||
2745 | ||
2746 | deBry, et al. Experimental [Page 49] | |
2747 | \f | |
2748 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2749 | ||
2750 | ||
2751 | the value, unless it would violate the security policy. See the | |
2752 | description of the "out-of-band" values in the beginning of | |
2753 | Section 4.1. | |
2754 | ||
2755 | Jobs are returned in the following order: | |
2756 | ||
2757 | - If the client requests all 'completed' Jobs (Jobs in the ' | |
2758 | completed', 'aborted', or 'canceled' states), then the Jobs | |
2759 | are returned newest to oldest (with respect to actual | |
2760 | completion time) | |
2761 | - If the client requests all 'not-completed' Jobs (Jobs in the | |
2762 | 'pending', 'processing', 'pending-held', and 'processing- | |
2763 | stopped' states), then Jobs are returned in relative | |
2764 | chronological order of expected time to complete (based on | |
2765 | whatever scheduling algorithm is configured for the Printer | |
2766 | object). | |
2767 | ||
2768 | 3.3 Job Operations | |
2769 | ||
2770 | All Job operations are directed at Job objects. A client MUST always | |
2771 | supply some means of identifying the Job object in order to identify | |
2772 | the correct target of the operation. That job identification MAY | |
2773 | either be a single Job URI or a combination of a Printer URI with a | |
2774 | Job ID. The IPP object implementation MUST support both forms of | |
2775 | identification for every job. | |
2776 | ||
2777 | 3.3.1 Send-Document Operation | |
2778 | ||
2779 | This OPTIONAL operation allows a client to create a multi-document | |
2780 | Job object that is initially "empty" (contains no documents). In the | |
2781 | Create-Job response, the Printer object returns the Job object's URI | |
2782 | (the "job-uri" attribute) and the Job object's 32-bit identifier (the | |
2783 | "job-id" attribute). For each new document that the client desires | |
2784 | to add, the client uses a Send-Document operation. Each Send- | |
2785 | Document Request contains the entire stream of document data for one | |
2786 | document. | |
2787 | ||
2788 | Since the Create-Job and the send operations (Send-Document or Send- | |
2789 | URI operations) that follow could occur over an arbitrarily long | |
2790 | period of time for a particular job, a client MUST send another send | |
2791 | operation within an IPP Printer defined minimum time interval after | |
2792 | the receipt of the previous request for the job. If a Printer object | |
2793 | supports multiple document jobs, the Printer object MUST support the | |
2794 | "multiple-operation-time-out" attribute (see section 4.4.28). This | |
2795 | attribute indicates the minimum number of seconds the Printer object | |
2796 | will wait for the next send operation before taking some recovery | |
2797 | action. | |
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | deBry, et al. Experimental [Page 50] | |
2803 | \f | |
2804 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2805 | ||
2806 | ||
2807 | An IPP object MUST recover from an errant client that does not supply | |
2808 | a send operation, sometime after the minimum time interval specified | |
2809 | by the Printer object's "multiple-operation-time-out" attribute. | |
2810 | Such recovery MAY include any of the following or other recovery | |
2811 | actions: | |
2812 | ||
2813 | 1. Assume that the Job is an invalid job, start the process of | |
2814 | changing the job state to 'aborted', add the 'aborted-by-system' | |
2815 | value to the job's "job-state-reasons" attribute (see section | |
2816 | 4.3.8), if supported, and clean up all resources associated with | |
2817 | the Job. In this case, if another send operation is finally | |
2818 | received, the Printer responds with an "client-error-not- | |
2819 | possible" or "client-error-not-found" depending on whether or | |
2820 | not the Job object is still around when the send operation | |
2821 | finally arrives. | |
2822 | 2. Assume that the last send operation received was in fact the | |
2823 | last document (as if the "last-document" flag had been set to ' | |
2824 | true'), close the Job object, and proceed to process it (i.e., | |
2825 | move the Job's state to 'pending'). | |
2826 | 3. Assume that the last send operation received was in fact the | |
2827 | last document, close the Job, but move it to the 'pending-held' | |
2828 | and add the 'submission-interrupted' value to the job's "job- | |
2829 | state-reasons" attribute (see section 4.3.8), if supported. | |
2830 | This action allows the user or an operator to determine whether | |
2831 | to continue processing the Job by moving it back to the ' | |
2832 | pending' state or to cancel the job. | |
2833 | ||
2834 | Each implementation is free to decide the "best" action to take | |
2835 | depending on local policy, whether any documents have been added, | |
2836 | whether the implementation spools jobs or not, and/or any other piece | |
2837 | of information available to it. If the choice is to abort the Job | |
2838 | object, it is possible that the Job object may already have been | |
2839 | processed to the point that some media sheet pages have been printed. | |
2840 | ||
2841 | 3.3.1.1 Send-Document Request | |
2842 | ||
2843 | The following attribute sets are part of the Send-Document Request: | |
2844 | ||
2845 | Group 1: Operation Attributes | |
2846 | ||
2847 | Natural Language and Character Set: | |
2848 | The "attributes-charset" and "attributes-natural-language" | |
2849 | attributes as described in section 3.1.4.1. | |
2850 | ||
2851 | ||
2852 | ||
2853 | ||
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | deBry, et al. Experimental [Page 51] | |
2859 | \f | |
2860 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2861 | ||
2862 | ||
2863 | Target: | |
2864 | Either (1) the "printer-uri" (uri) plus "job-id" | |
2865 | (integer(1:MAX))or (2) the "job-uri" (uri) operation | |
2866 | attribute(s) which define the target for this operation as | |
2867 | described in section 3.1.5. | |
2868 | ||
2869 | Requesting User Name: | |
2870 | "requesting-user-name" (name(MAX)) attribute SHOULD be supplied | |
2871 | by the client as described in section 8.3. | |
2872 | ||
2873 | "document-name" (name(MAX)): | |
2874 | The client OPTIONALLY supplies this attribute. The Printer | |
2875 | object MUST support this attribute. It contains the client | |
2876 | supplied document name. The document name MAY be different than | |
2877 | the Job name. It might be helpful, but NEED NOT be unique | |
2878 | across multiple documents in the same Job. Typically, the | |
2879 | client software automatically supplies the document name on | |
2880 | behalf of the end user by using a file name or an application | |
2881 | generated name. See the description of the "document-name" | |
2882 | operation attribute in the Print-Job Request (section 3.2.1.1) | |
2883 | for more information about this attribute | |
2884 | ||
2885 | "document-format" (mimeMediaType): | |
2886 | The client OPTIONALLY supplies this attribute. The Printer | |
2887 | object MUST support this attribute. The value of this attribute | |
2888 | identifies the format of the supplied document data. If the | |
2889 | client does not supply this attribute, the Printer object | |
2890 | assumes that the document data is in the format defined by the | |
2891 | Printer object's "document-format-default" attribute. If the | |
2892 | client supplies this attribute, but the value is not supported | |
2893 | by the Printer object, i.e., the value is not one of the values | |
2894 | of the Printer object's "document-format-supported" attribute, | |
2895 | the Printer object MUST reject the request and return the ' | |
2896 | client-error-document-format-not-supported' status code. | |
2897 | ||
2898 | "document-natural-language" (naturalLanguage): | |
2899 | The client OPTIONALLY supplies this attribute. The Printer | |
2900 | object OPTIONALLY supports this attribute. This attribute | |
2901 | specifies the natural language of the document for those | |
2902 | document-formats that require a specification of the natural | |
2903 | language in order to image the document unambiguously. There | |
2904 | are no particular values required for the Printer object to | |
2905 | support. | |
2906 | ||
2907 | "compression" (type3 keyword) | |
2908 | The client OPTIONALLY supplies this attribute. The Printer | |
2909 | object OPTIONALLY supports this attribute and the "compression- | |
2910 | supported" attribute (see section 4.4.29). The client supplied | |
2911 | ||
2912 | ||
2913 | ||
2914 | deBry, et al. Experimental [Page 52] | |
2915 | \f | |
2916 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2917 | ||
2918 | ||
2919 | "compression" operation attribute identifies the compression | |
2920 | algorithm used on the document data. If the client omits this | |
2921 | attribute, the Printer object MUST assume that the data is not | |
2922 | compressed. If the client supplies the attribute and the | |
2923 | Printer object supports the attribute, the Printer object MUST | |
2924 | use the corresponding decompression algorithm on the document | |
2925 | data. If the client supplies this attribute, but the value is | |
2926 | not supported by the Printer object, i.e., the value is not one | |
2927 | of the values of the Printer object's "compression-supported" | |
2928 | attribute, the Printer object MUST copy the attribute and its | |
2929 | value to the Unsupported Attributes response group, reject the | |
2930 | request, and return the 'client-error-attributes-or-values-not- | |
2931 | supported' status code. | |
2932 | ||
2933 | "last-document" (boolean): | |
2934 | The client MUST supply this attribute. The Printer object MUST | |
2935 | support this attribute. It is a boolean flag that is set to ' | |
2936 | true' if this is the last document for the Job, 'false' | |
2937 | otherwise. | |
2938 | ||
2939 | Group 2: Document Content | |
2940 | ||
2941 | The client MUST supply the document data if the "last-document" | |
2942 | flag is set to 'false'. However, since a client might not know | |
2943 | that the previous document sent with a Send-Document (or Send- | |
2944 | URI) operation was the last document (i.e., the "last-document" | |
2945 | attribute was set to 'false'), it is legal to send a Send- | |
2946 | Document request with no document data where the "last-document" | |
2947 | flag is set to 'true'. Such a request MUST NOT increment the | |
2948 | value of the Job object's "number-of-documents" attribute, since | |
2949 | no real document was added to the job. | |
2950 | ||
2951 | 3.3.1.2 Send-Document Response | |
2952 | ||
2953 | The following sets of attributes are part of the Send-Document | |
2954 | Response: | |
2955 | ||
2956 | Group 1: Operation Attributes | |
2957 | ||
2958 | Status Message: | |
2959 | In addition to the REQUIRED status code returned in every | |
2960 | response, the response OPTIONALLY includes a "status-message" | |
2961 | (text) operation attribute as described in sections 14 and | |
2962 | 3.1.6. | |
2963 | ||
2964 | Natural Language and Character Set: | |
2965 | The "attributes-charset" and "attributes-natural-language" | |
2966 | attributes as described in section 3.1.4.2. | |
2967 | ||
2968 | ||
2969 | ||
2970 | deBry, et al. Experimental [Page 53] | |
2971 | \f | |
2972 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
2973 | ||
2974 | ||
2975 | Group 2: Unsupported Attributes | |
2976 | ||
2977 | This is a set of Operation attributes supplied by the client (in | |
2978 | the request) that are not supported by the Printer object or | |
2979 | that conflict with one another (see sections 3.2.1.2 and the | |
2980 | Implementer's Guide [ipp-iig]). If the Printer object is not | |
2981 | returning any Unsupported Attributes in the response, the | |
2982 | Printer object SHOULD omit Group 2 rather than sending an empty | |
2983 | group. However, a client MUST be able to accept an empty group. | |
2984 | ||
2985 | Group 3: Job Object Attributes | |
2986 | ||
2987 | This is the same set of attributes as described in the Print-Job | |
2988 | response (see section 3.2.1.2). | |
2989 | ||
2990 | 3.3.2 Send-URI Operation | |
2991 | ||
2992 | This OPTIONAL operation is identical to the Send-Document operation | |
2993 | (see section 3.3.1) except that a client MUST supply a URI reference | |
2994 | ("document-uri" operation attribute) rather than the document data | |
2995 | itself. If a Printer object supports this operation, clients can use | |
2996 | both Send-URI or Send-Document operations to add new documents to an | |
2997 | existing multi-document Job object. However, if a client needs to | |
2998 | indicate that the previous Send-URI or Send-Document was the last | |
2999 | document, the client MUST use the Send-Document operation with no | |
3000 | document data and the "last-document" flag set to 'true' (rather than | |
3001 | using a Send-URI operation with no "document-uri" operation | |
3002 | attribute). | |
3003 | ||
3004 | If a Printer object supports this operation, it MUST also support the | |
3005 | Print-URI operation (see section 3.2.2). | |
3006 | ||
3007 | The Printer object MUST validate the syntax and URI scheme of the | |
3008 | supplied URI before returning a response, just as in the Print-URI | |
3009 | operation. | |
3010 | ||
3011 | 3.3.3 Cancel-Job Operation | |
3012 | ||
3013 | This REQUIRED operation allows a client to cancel a Print Job from | |
3014 | the time the job is created up to the time it is completed, canceled, | |
3015 | or aborted. Since a Job might already be printing by the time a | |
3016 | Cancel-Job is received, some media sheet pages might be printed | |
3017 | before the job is actually terminated. | |
3018 | ||
3019 | 3.3.3.1 Cancel-Job Request | |
3020 | ||
3021 | The following groups of attributes are part of the Cancel-Job | |
3022 | Request: | |
3023 | ||
3024 | ||
3025 | ||
3026 | deBry, et al. Experimental [Page 54] | |
3027 | \f | |
3028 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3029 | ||
3030 | ||
3031 | Group 1: Operation Attributes | |
3032 | ||
3033 | Natural Language and Character Set: | |
3034 | The "attributes-charset" and "attributes-natural-language" | |
3035 | attributes as described in section 3.1.4.1. | |
3036 | ||
3037 | Target: | |
3038 | Either (1) the "printer-uri" (uri) plus "job-id" | |
3039 | (integer(1:MAX))or (2) the "job-uri" (uri) operation | |
3040 | attribute(s) which define the target for this operation as | |
3041 | described in section 3.1.5. | |
3042 | ||
3043 | Requesting User Name: | |
3044 | The "requesting-user-name" (name(MAX)) attribute SHOULD be | |
3045 | supplied by the client as described in section 8.3. | |
3046 | ||
3047 | "message" (text(127)): | |
3048 | The client OPTIONALLY supplies this attribute. The Printer | |
3049 | object OPTIONALLY supports this attribute. It is a message to | |
3050 | the operator. This "message" attribute is not the same as the | |
3051 | "job-message-from-operator" attribute. That attribute is used | |
3052 | to report a message from the operator to the end user that | |
3053 | queries that attribute. This "message" operation attribute is | |
3054 | used to send a message from the client to the operator along | |
3055 | with the operation request. It is an implementation decision of | |
3056 | how or where to display this message to the operator (if at | |
3057 | all). | |
3058 | ||
3059 | 3.3.3.2 Cancel-Job Response | |
3060 | ||
3061 | The following sets of attributes are part of the Cancel-Job Response: | |
3062 | ||
3063 | Group 1: Operation Attributes | |
3064 | ||
3065 | Status Message: | |
3066 | In addition to the REQUIRED status code returned in every | |
3067 | response, the response OPTIONALLY includes a "status-message" | |
3068 | (text) operation attribute as described in sections 14 and | |
3069 | 3.1.6. | |
3070 | ||
3071 | If the job is already in the 'completed', 'aborted', or ' | |
3072 | canceled' state, or the 'process-to-stop-point' value is set in | |
3073 | the Job's "job-state-reasons" attribute, the Printer object MUST | |
3074 | reject the request and return the 'client-error-not-possible' | |
3075 | error status code. | |
3076 | ||
3077 | ||
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | deBry, et al. Experimental [Page 55] | |
3083 | \f | |
3084 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3085 | ||
3086 | ||
3087 | Natural Language and Character Set: | |
3088 | The "attributes-charset" and "attributes-natural-language" | |
3089 | attributes as described in section 3.1.4.2. | |
3090 | ||
3091 | Group 2: Unsupported Attributes | |
3092 | ||
3093 | This is a set of Operation attributes supplied by the client (in | |
3094 | the request) that are not supported by the Printer object or | |
3095 | that conflict with one another (see section 3.2.1.2 and the | |
3096 | Implementer's Guide [ipp-iig]). If the Printer object is not | |
3097 | returning any Unsupported Attributes in the response, the | |
3098 | Printer object SHOULD omit Group 2 rather than sending an empty | |
3099 | group. However, a client MUST be able to accept an empty group. | |
3100 | ||
3101 | Once a successful response has been sent, the implementation | |
3102 | guarantees that the Job will eventually end up in the 'canceled' | |
3103 | state. Between the time of the Cancel-Job operation is accepted and | |
3104 | when the job enters the 'canceled' job-state (see section 4.3.7), the | |
3105 | "job-state-reasons" attribute SHOULD contain the 'processing-to- | |
3106 | stop-point' value which indicates to later queries that although the | |
3107 | Job might still be 'processing', it will eventually end up in the ' | |
3108 | canceled' state, not the 'completed' state. | |
3109 | ||
3110 | 3.3.4 Get-Job-Attributes Operation | |
3111 | ||
3112 | This REQUIRED operation allows a client to request the values of | |
3113 | attributes of a Job object and it is almost identical to the Get- | |
3114 | Printer-Attributes operation (see section 3.2.5). The only | |
3115 | differences are that the operation is directed at a Job object rather | |
3116 | than a Printer object, there is no "document-format" operation | |
3117 | attribute used when querying a Job object, and the returned attribute | |
3118 | group is a set of Job object attributes rather than a set of Printer | |
3119 | object attributes. | |
3120 | ||
3121 | For Jobs, the possible names of attribute groups are: | |
3122 | ||
3123 | - 'job-template': all of the Job Template attributes that apply to a | |
3124 | Job object (the first column of the table in Section 4.2). | |
3125 | - 'job-description': all of the Job Description attributes specified | |
3126 | in Section 4.3. | |
3127 | - 'all': the special group 'all' that includes all supported | |
3128 | attributes. | |
3129 | ||
3130 | Since a client MAY request specific attributes or named groups, there | |
3131 | is a potential that there is some overlap. For example, if a client | |
3132 | requests, 'job-name' and 'job-description', the client is actually | |
3133 | requesting the "job-name" attribute once by naming it explicitly, and | |
3134 | once by inclusion in the 'job-description' group. In such cases, the | |
3135 | ||
3136 | ||
3137 | ||
3138 | deBry, et al. Experimental [Page 56] | |
3139 | \f | |
3140 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3141 | ||
3142 | ||
3143 | Printer object NEED NOT return the attribute only once in the | |
3144 | response even if it is requested multiple times. The client SHOULD | |
3145 | NOT request the same attribute in multiple ways. | |
3146 | ||
3147 | It is NOT REQUIRED that a Job object support all attributes belonging | |
3148 | to a group (since some attributes are OPTIONAL). However it is | |
3149 | REQUIRED that each Job object support all group names. | |
3150 | ||
3151 | 3.3.4.1 Get-Job-Attributes Request | |
3152 | ||
3153 | The following groups of attributes are part of the Get-Job-Attributes | |
3154 | Request when the request is directed at a Job object: | |
3155 | ||
3156 | Group 1: Operation Attributes | |
3157 | ||
3158 | Natural Language and Character Set: | |
3159 | The "attributes-charset" and "attributes-natural-language" | |
3160 | attributes as described in section 3.1.4.1. | |
3161 | ||
3162 | Target: | |
3163 | Either (1) the "printer-uri" (uri) plus "job-id" | |
3164 | (integer(1:MAX)) or (2) the "job-uri" (uri) operation | |
3165 | attribute(s) which define the target for this operation as | |
3166 | described in section 3.1.5. | |
3167 | ||
3168 | Requesting User Name: | |
3169 | The "requesting-user-name" (name(MAX)) attribute SHOULD be | |
3170 | supplied by the client as described in section 8.3. | |
3171 | ||
3172 | "requested-attributes" (1setOf keyword) : | |
3173 | The client OPTIONALLY supplies this attribute. The IPP object | |
3174 | MUST support this attribute. It is a set of attribute names | |
3175 | and/or attribute group names in whose values the requester is | |
3176 | interested. If the client omits this attribute, the IPP object | |
3177 | MUST respond as if this attribute had been supplied with a value | |
3178 | of 'all'. | |
3179 | ||
3180 | 3.3.4.2 Get-Job-Attributes Response | |
3181 | ||
3182 | The Printer object returns the following sets of attributes as part | |
3183 | of the Get-Job-Attributes Response: | |
3184 | ||
3185 | ||
3186 | ||
3187 | ||
3188 | ||
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | deBry, et al. Experimental [Page 57] | |
3195 | \f | |
3196 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3197 | ||
3198 | ||
3199 | Group 1: Operation Attributes | |
3200 | ||
3201 | Status Message: | |
3202 | In addition to the REQUIRED status code returned in every | |
3203 | response, the response OPTIONALLY includes a "status-message" | |
3204 | (text) operation attribute as described in sections 14 and | |
3205 | 3.1.6. | |
3206 | ||
3207 | Natural Language and Character Set: | |
3208 | The "attributes-charset" and "attributes-natural-language" | |
3209 | attributes as described in section 3.1.4.2. The "attributes- | |
3210 | natural-language" MAY be the natural language of the Job object, | |
3211 | rather than the one requested. | |
3212 | ||
3213 | Group 2: Unsupported Attributes | |
3214 | ||
3215 | This is a set of Operation attributes supplied by the client (in | |
3216 | the request) that are not supported by the Printer object or | |
3217 | that conflict with one another (see sections 3.2.1.2 and the | |
3218 | Implementer's Guide [ipp-iig]). The response NEED NOT contain | |
3219 | the "requested-attributes" operation attribute with any supplied | |
3220 | values (attribute keywords) that were requested by the client | |
3221 | but are not supported by the IPP object. If the Printer object | |
3222 | is not returning any Unsupported Attributes in the response, the | |
3223 | Printer object SHOULD omit Group 2 rather than sending an empty | |
3224 | group. However, a client MUST be able to accept an empty group. | |
3225 | ||
3226 | Group 3: Job Object Attributes | |
3227 | ||
3228 | This is the set of requested attributes and their current | |
3229 | values. The IPP object ignores (does not respond with) any | |
3230 | requested attribute or value which is not supported or which is | |
3231 | restricted by the security policy in force, including whether | |
3232 | the requesting user is the user that submitted the job (job | |
3233 | originating user) or not (see section 8). However, the IPP | |
3234 | object MUST respond with the 'unknown' value for any supported | |
3235 | attribute (including all RED butes) for which the IPP object | |
3236 | does not know the value, s it would violate the security policy. | |
3237 | See the description e "out-of-band" values in the beginning of | |
3238 | Section 4.1. | |
3239 | ||
3240 | 4. Object Attributes | |
3241 | ||
3242 | This section describes the attributes with their corresponding | |
3243 | attribute syntaxes and values that are part of the IPP model. The | |
3244 | sections below show the objects and their associated attributes which | |
3245 | are included within the scope of this protocol. Many of these | |
3246 | attributes are derived from other relevant specifications: | |
3247 | ||
3248 | ||
3249 | ||
3250 | deBry, et al. Experimental [Page 58] | |
3251 | \f | |
3252 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3253 | ||
3254 | ||
3255 | - Document Printing Application (DPA) [ISO10175] | |
3256 | - RFC 1759 Printer MIB [RFC1759] | |
3257 | ||
3258 | Each attribute is uniquely identified in this document using a | |
3259 | "keyword" (see section 12.2.1) which is the name of the attribute. | |
3260 | The keyword is included in the section header describing that | |
3261 | attribute. | |
3262 | ||
3263 | Note: Not only are keywords used to identify attributes, but one of | |
3264 | the attribute syntaxes described below is "keyword" so that some | |
3265 | attributes have keyword values. Therefore, these attributes are | |
3266 | defined as having an attribute syntax that is a set of keywords. | |
3267 | ||
3268 | 4.1 Attribute Syntaxes | |
3269 | ||
3270 | This section defines the basic attribute syntax types that all clients | |
3271 | and IPP objects MUST be able to accept in responses and accept in | |
3272 | requests, respectively. Each attribute description in sections 3 and | |
3273 | 4 includes the name of attribute syntax(es) in the heading (in | |
3274 | parentheses). A conforming implementation of an attribute MUST | |
3275 | include the semantics of the attribute syntax(es) so identified. | |
3276 | Section 6.3 describes how the protocol can be extended with new | |
3277 | attribute syntaxes. | |
3278 | ||
3279 | The attribute syntaxes are specified in the following sub-sections, | |
3280 | where the sub-section heading is the keyword name of the attribute | |
3281 | syntax inside the single quotes. In operation requests and responses | |
3282 | each attribute value MUST be represented as one of the attribute | |
3283 | syntaxes specified in the sub-section heading for the attribute. In | |
3284 | addition, the value of an attribute in a response (but not in a | |
3285 | request) MAY be one of the "out-of-band" values. Standard | |
3286 | "out-of-band" values are: | |
3287 | ||
3288 | 'unknown': The attribute is supported by the IPP object, but the | |
3289 | value is unknown to the IPP object for some reason. | |
3290 | 'unsupported': The attribute is unsupported by the IPP object. This | |
3291 | value MUST be returned only as the value of an attribute in the | |
3292 | Unsupported Attributes Group. | |
3293 | 'no-value': The attribute is supported by the Printer object, but | |
3294 | the system administrator has not yet configured a value. | |
3295 | ||
3296 | The Encoding and Transport specification [RFC2565] defines mechanisms | |
3297 | for passing "out-of-band" values. All attributes in a request MUST | |
3298 | have one or more values as defined in Sections 4.2 to 4.4. Thus | |
3299 | clients MUST NOT supply attributes with "out-of-band" values. All | |
3300 | attribute in a response MUST have one or more values as defined in | |
3301 | Sections 4.2 to 4.4 or a single "out-of-band" value. | |
3302 | ||
3303 | ||
3304 | ||
3305 | ||
3306 | deBry, et al. Experimental [Page 59] | |
3307 | \f | |
3308 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3309 | ||
3310 | ||
3311 | Most attributes are defined to have a single attribute syntax. | |
3312 | However, a few attributes (e.g., "job-sheet", "media", "job-hold- | |
3313 | until") are defined to have several attribute syntaxes, depending on | |
3314 | the value. These multiple attribute syntaxes are separated by the | |
3315 | "|" character in the sub-section heading to indicate the choice. | |
3316 | Since each value MUST be tagged as to its attribute syntax in the | |
3317 | ||
3318 | protocol, a single-valued attribute instance may have any one of its | |
3319 | attribute syntaxes and a multi-valued attribute instance may have a | |
3320 | mixture of its defined attribute syntaxes. | |
3321 | ||
3322 | 4.1.1 'text' | |
3323 | ||
3324 | A text attribute is an attribute whose value is a sequence of zero or | |
3325 | more characters encoded in a maximum of 1023 ('MAX') octets. MAX is | |
3326 | the maximum length for each value of any text attribute. However, if | |
3327 | an attribute will always contain values whose maximum length is much | |
3328 | less than MAX, the definition of that attribute will include a | |
3329 | qualifier that defines the maximum length for values of that | |
3330 | attribute. For example: the "printer-location" attribute is | |
3331 | specified as "printer-location (text(127))". In this case, text | |
3332 | values for "printer-location" MUST NOT exceed 127 octets; if supplied | |
3333 | with a longer text string via some external interface (other than the | |
3334 | protocol), implementations are free to truncate to this shorter | |
3335 | length limitation. | |
3336 | ||
3337 | In this specification, all text attributes are defined using the ' | |
3338 | text' syntax. However, 'text' is used only for brevity; the formal | |
3339 | interpretation of 'text' is: 'textWithoutLanguage | | |
3340 | textWithLanguage'. That is, for any attribute defined in this | |
3341 | specification using the 'text' attribute syntax, all IPP objects and | |
3342 | clients MUST support both the 'textWithoutLanguage' and ' | |
3343 | textWithLanguage' attribute syntaxes. However, in actual usage and | |
3344 | protocol execution, objects and clients accept and return only one of | |
3345 | the two syntax per attribute. The syntax 'text' never appears "on- | |
3346 | the-wire". | |
3347 | ||
3348 | Both 'textWithoutLanguage' and 'textWithLanguage' are needed to | |
3349 | support the real world needs of interoperability between sites and | |
3350 | systems that use different natural languages as the basis for human | |
3351 | communication. Generally, one natural language applies to all text | |
3352 | attributes in a given request or response. The language is indicated | |
3353 | by the "attributes-natural-language" operation attribute defined in | |
3354 | section 3.1.4 or "attributes-natural-language" job attribute defined | |
3355 | in section 4.3.24, and there is no need to identify the natural | |
3356 | language for each text string on a value-by-value basis. In these | |
3357 | cases, the attribute syntax 'textWithoutLanguage' is used for text | |
3358 | attributes. In other cases, the client needs to supply or the | |
3359 | ||
3360 | ||
3361 | ||
3362 | deBry, et al. Experimental [Page 60] | |
3363 | \f | |
3364 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3365 | ||
3366 | ||
3367 | Printer object needs to return a text value in a natural language | |
3368 | that is different from the rest of the text values in the request or | |
3369 | response. In these cases, the client or Printer object uses the | |
3370 | attribute syntax 'textWithLanguage' for text attributes (this is the | |
3371 | Natural Language Override mechanism described in section 3.1.4). | |
3372 | ||
3373 | The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes | |
3374 | are described in more detail in the following sections. | |
3375 | ||
3376 | 4.1.1.1 'textWithoutLanguage' | |
3377 | ||
3378 | The 'textWithoutLanguage' syntax indicates a value that is sequence | |
3379 | of zero or more characters. Text strings are encoded using the rules | |
3380 | of some charset. The Printer object MUST support the UTF-8 charset | |
3381 | [RFC2279] and MAY support additional charsets to represent 'text' | |
3382 | values, provided that the charsets are registered with IANA [IANA- | |
3383 | CS]. See Section 4.1.7 for the specification of the 'charset' | |
3384 | attribute syntax, including restricted semantics and examples of | |
3385 | charsets. | |
3386 | ||
3387 | 4.1.1.2 'textWithLanguage' | |
3388 | ||
3389 | The 'textWithLanguage' attribute syntax is a compound attribute | |
3390 | syntax consisting of two parts: a 'textWithoutLanguage' part plus an | |
3391 | additional 'naturalLanguage' (see section 4.1.8) part that overrides | |
3392 | the natural language in force. The 'naturalLanguage' part explicitly | |
3393 | identifies the natural language that applies to the text part of that | |
3394 | value and that value alone. For any give text attribute, the ' | |
3395 | textWithoutLanguage' part is limited to the maximum length defined | |
3396 | for that attribute, but the 'naturalLanguage' part is always limited | |
3397 | to 63 octets. Using the 'textWithLanguage' attribute syntax rather | |
3398 | than the normal 'textWithoutLanguage' syntax is the so-called Natural | |
3399 | Language Override mechanism and MUST be supported by all IPP objects | |
3400 | and clients. | |
3401 | ||
3402 | If the attribute is multi-valued (1setOf text), then the ' | |
3403 | textWithLanguage' attribute syntax MUST be used to explicitly specify | |
3404 | each attribute value whose natural language needs to be overridden. | |
3405 | Other values in a multi-valued 'text' attribute in a request or a | |
3406 | response revert to the natural language of the operation attribute. | |
3407 | ||
3408 | In a create request, the Printer object MUST accept and store with | |
3409 | the Job object any natural language in the "attributes-natural- | |
3410 | language" operation attribute, whether the Printer object supports | |
3411 | that natural language or not. Furthermore, the Printer object MUST | |
3412 | accept and store any 'textWithLanguage' attribute value, whether the | |
3413 | ||
3414 | ||
3415 | ||
3416 | ||
3417 | ||
3418 | deBry, et al. Experimental [Page 61] | |
3419 | \f | |
3420 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3421 | ||
3422 | ||
3423 | Printer object supports that natural language or not. These | |
3424 | requirements are independent of the value of the "ipp-attribute- | |
3425 | fidelity" operation attribute that the client MAY supply. | |
3426 | ||
3427 | Example: If the client supplies the "attributes-natural-language" | |
3428 | operation attribute with the value: 'en' indicating English, but the | |
3429 | value of the "job-name" attribute is in French, the client MUST use | |
3430 | the 'textWithLanguage' attribute syntax with the following two | |
3431 | values: | |
3432 | ||
3433 | 'fr': Natural Language Override indicating French | |
3434 | 'Rapport Mensuel': the job name in French | |
3435 | ||
3436 | See the Encoding and Transport document [RFC2565] for a detailed | |
3437 | example of the 'textWithLanguage' attribute syntax. | |
3438 | ||
3439 | 4.1.2 'name' | |
3440 | ||
3441 | This syntax type is used for user-friendly strings, such as a Printer | |
3442 | name, that, for humans, are more meaningful than identifiers. Names | |
3443 | are never translated from one natural language to another. The ' | |
3444 | name' attribute syntax is essentially the same as 'text', including | |
3445 | the REQUIRED support of UTF-8 except that the sequence of characters | |
3446 | is limited so that its encoded form MUST NOT exceed 255 (MAX) octets. | |
3447 | ||
3448 | Also like 'text', 'name' is really an abbreviated notation for either | |
3449 | 'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP | |
3450 | objects and clients MUST support both the 'nameWithoutLanguage' and ' | |
3451 | nameWithLanguage' attribute syntaxes. However, in actual usage and | |
3452 | protocol execution, objects and clients accept and return only one of | |
3453 | the two syntax per attribute. The syntax 'name' never appears "on- | |
3454 | the-wire". | |
3455 | ||
3456 | Note: Only the 'text' and 'name' attribute syntaxes permit the | |
3457 | Natural Language Override mechanism. | |
3458 | ||
3459 | Some attributes are defined as 'type3 keyword | name'. These | |
3460 | attributes support values that are either type3 keywords or names. | |
3461 | This dual-syntax mechanism enables a site administrator to extend | |
3462 | these attributes to legally include values that are locally defined | |
3463 | by the site administrator. Such names are not registered with IANA. | |
3464 | ||
3465 | 4.1.2.1 'nameWithoutLanguage' | |
3466 | ||
3467 | The 'nameWithoutLanguage' syntax indicates a value that is sequence | |
3468 | of zero or more characters so that its encoded form does not exceed | |
3469 | MAX octets. | |
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | deBry, et al. Experimental [Page 62] | |
3475 | \f | |
3476 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3477 | ||
3478 | ||
3479 | 4.1.2.2 'nameWithLanguage' | |
3480 | ||
3481 | The 'nameWithLanguage' attribute syntax is a compound attribute | |
3482 | syntax consisting of two parts: a 'nameWithoutLanguage' part plus an | |
3483 | additional 'naturalLanguage' (see section 4.1.8) part that overrides | |
3484 | the natural language in force. The 'naturalLanguage' part explicitly | |
3485 | identifies the natural language that applies to that name value and | |
3486 | that name value alone. | |
3487 | ||
3488 | The 'nameWithLanguage' attribute syntax behaves the same as the ' | |
3489 | textWithLanguage' syntax. If a name is in a language that is | |
3490 | different than the rest of the object or operation, then this ' | |
3491 | nameWithLanguage' syntax is used rather than the generic ' | |
3492 | nameWithoutLanguage' syntax. | |
3493 | ||
3494 | Example: If the client supplies the "attributes-natural-language" | |
3495 | operation attribute with the value: 'en' indicating English, but the | |
3496 | "printer-name" attribute is in German, the client MUST use the ' | |
3497 | nameWithLanguage' attribute syntax as follows: | |
3498 | ||
3499 | 'de': Natural Language Override indicating German | |
3500 | 'Farbdrucker': the Printer name in German | |
3501 | ||
3502 | 4.1.2.3 Matching 'name' attribute values | |
3503 | ||
3504 | For purposes of matching two 'name' attribute values for equality, | |
3505 | such as in job validation (where a client-supplied value for | |
3506 | attribute "xxx" is checked to see if the value is among the values of | |
3507 | the Printer object's corresponding "xxx-supported" attribute), the | |
3508 | following match rules apply: | |
3509 | ||
3510 | 1. 'keyword' values never match 'name' values. | |
3511 | ||
3512 | 2. 'name' (nameWithoutLanguage and nameWithLanguage) values | |
3513 | match if (1) the name parts match and (2) the Associated | |
3514 | Natural-Language parts (see section 3.1.4.1) match. The | |
3515 | matching rules are: | |
3516 | ||
3517 | a. the name parts match if the two names are identical | |
3518 | character by character, except it is RECOMMENDED that case | |
3519 | be ignored. For example: 'Ajax-letter-head-white' MUST | |
3520 | match 'Ajax-letter-head-white' and SHOULD match 'ajax- | |
3521 | letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'. | |
3522 | ||
3523 | b. the Associated Natural-Language parts match if the | |
3524 | shorter of the two meets the syntactic requirements of RFC | |
3525 | 1766 [RFC1766] and matches byte for byte with the longer. | |
3526 | For example, 'en' matches 'en', 'en-us' and 'en-gb', but | |
3527 | ||
3528 | ||
3529 | ||
3530 | deBry, et al. Experimental [Page 63] | |
3531 | \f | |
3532 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3533 | ||
3534 | ||
3535 | matches neither 'fr' nor 'e'. | |
3536 | ||
3537 | 4.1.3 'keyword' | |
3538 | ||
3539 | The 'keyword' attribute syntax is a sequence of characters, length: 1 | |
3540 | to 255, containing only the US-ASCII [ASCII] encoded values for | |
3541 | lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot | |
3542 | ("."), and underscore ("_"). The first character MUST be a lowercase | |
3543 | letter. Furthermore, keywords MUST be in U.S. English. | |
3544 | ||
3545 | This syntax type is used for enumerating semantic identifiers of | |
3546 | entities in the abstract protocol, i.e., entities identified in this | |
3547 | document. Keywords are used as attribute names or values of | |
3548 | attributes. Unlike 'text' and 'name' attribute values, 'keyword' | |
3549 | values MUST NOT use the Natural Language Override mechanism, since | |
3550 | they MUST always be US-ASCII and U.S. English. | |
3551 | ||
3552 | Keywords are for use in the protocol. A user interface will likely | |
3553 | provide a mapping between protocol keywords and displayable user- | |
3554 | friendly words and phrases which are localized to the natural | |
3555 | language of the user. While the keywords specified in this document | |
3556 | MAY be displayed to users whose natural language is U.S. English, | |
3557 | they MAY be mapped to other U.S. English words for U.S. English | |
3558 | users, since the user interface is outside the scope of this | |
3559 | document. | |
3560 | ||
3561 | In the definition for each attribute of this syntax type, the full | |
3562 | set of defined keyword values for that attribute are listed. | |
3563 | ||
3564 | When a keyword is used to represent an attribute (its name), it MUST | |
3565 | be unique within the full scope of all IPP objects and attributes. | |
3566 | When a keyword is used to represent a value of an attribute, it MUST | |
3567 | be unique just within the scope of that attribute. That is, the same | |
3568 | keyword MUST NOT be used for two different values within the same | |
3569 | attribute to mean two different semantic ideas. However, the same | |
3570 | keyword MAY be used across two or more attributes, representing | |
3571 | different semantic ideas for each attribute. Section 6.1 describes | |
3572 | how the protocol can be extended with new keyword values. Examples | |
3573 | of attribute name keywords: | |
3574 | ||
3575 | "job-name" | |
3576 | "attributes-charset" | |
3577 | ||
3578 | Note: This document uses "type1", "type2", and "type3" prefixes to | |
3579 | the "keyword" basic syntax to indicate different levels of review for | |
3580 | extensions (see section 6.1). | |
3581 | ||
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | deBry, et al. Experimental [Page 64] | |
3587 | \f | |
3588 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3589 | ||
3590 | ||
3591 | 4.1.4 'enum' | |
3592 | ||
3593 | The 'enum' attribute syntax is an enumerated integer value that is in | |
3594 | the range from 1 to 2**31 - 1 (MAX). Each value has an associated ' | |
3595 | keyword' name. In the definition for each attribute of this syntax | |
3596 | type, the full set of possible values for that attribute are listed. | |
3597 | This syntax type is used for attributes for which there are enum | |
3598 | values assigned by other standards, such as SNMP MIBs. A number of | |
3599 | attribute enum values in this specification are also used for | |
3600 | corresponding attributes in other standards [RFC1759]. This syntax | |
3601 | type is not used for attributes to which the system administrator may | |
3602 | assign values. Section 6.1 describes how the protocol can be | |
3603 | extended with new enum values. | |
3604 | ||
3605 | Enum values are for use in the protocol. A user interface will | |
3606 | provide a mapping between protocol enum values and displayable user- | |
3607 | friendly words and phrases which are localized to the natural | |
3608 | language of the user. While the enum symbols specified in this | |
3609 | document MAY be displayed to users whose natural language is U.S. | |
3610 | English, they MAY be mapped to other U.S. English words for U.S. | |
3611 | English users, since the user interface is outside the scope of this | |
3612 | document. | |
3613 | ||
3614 | Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP | |
3615 | "out-of-band" value 'unknown'. See the description of the "out-of- | |
3616 | band" values at the beginning of Section 4.1. Therefore, attributes | |
3617 | of type 'enum' start at '3'. | |
3618 | ||
3619 | Note: This document uses "type1", "type2", and "type3" prefixes to | |
3620 | the "enum" basic syntax to indicate different levels of review for | |
3621 | extensions (see section 6.1). | |
3622 | ||
3623 | 4.1.5 'uri' | |
3624 | ||
3625 | The 'uri' attribute syntax is any valid Uniform Resource Identifier | |
3626 | or URI [RFC2396]. Most often, URIs are simply Uniform Resource | |
3627 | Locators or URLs. The maximum length of URIs used as values of IPP | |
3628 | attributes is 1023 octets. Although most other IPP attribute syntax | |
3629 | types allow for only lower-cased values, this attribute syntax type | |
3630 | conforms to the case-sensitive and case-insensitive rules specified | |
3631 | in [RFC2396]. | |
3632 | ||
3633 | 4.1.6 'uriScheme' | |
3634 | ||
3635 | The 'uriScheme' attribute syntax is a sequence of characters | |
3636 | representing a URI scheme according to RFC 2396 [RFC2396]. Though | |
3637 | RFC 2396 requires that the values be case-insensitive, IPP requires | |
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | deBry, et al. Experimental [Page 65] | |
3643 | \f | |
3644 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3645 | ||
3646 | ||
3647 | all lower case values in IPP attributes to simplify comparing by IPP | |
3648 | clients and Printer objects. Standard values for this syntax type | |
3649 | are the following keywords: | |
3650 | ||
3651 | 'http': for HTTP schemed URIs (e.g., "http:...") | |
3652 | 'https': for use with HTTPS schemed URIs (e.g., "https:...") | |
3653 | (not on IETF standards track) | |
3654 | 'ftp': for FTP schemed URIs (e.g., "ftp:...") | |
3655 | 'mailto': for SMTP schemed URIs (e.g., "mailto:...") | |
3656 | 'file': for file schemed URIs (e.g., "file:...") | |
3657 | ||
3658 | A Printer object MAY support any URI 'scheme' that has been | |
3659 | registered with IANA [IANA-MT]. The maximum length of URI 'scheme' | |
3660 | values used to represent IPP attribute values is 63 octets. | |
3661 | ||
3662 | 4.1.7 'charset' | |
3663 | ||
3664 | The 'charset' attribute syntax is a standard identifier for a | |
3665 | charset. A charset is a coded character set and encoding scheme. | |
3666 | Charsets are used for labeling certain document contents and 'text' | |
3667 | and 'name' attribute values. The syntax and semantics of this | |
3668 | attribute syntax are specified in RFC 2046 [RFC2046] and contained in | |
3669 | the IANA character-set Registry [IANA-CS] according to the IANA | |
3670 | procedures [RFC2278]. Though RFC 2046 requires that the values be | |
3671 | case-insensitive US-ASCII, IPP requires all lower case values in IPP | |
3672 | attributes to simplify comparing by IPP clients and Printer objects. | |
3673 | When a character-set in the IANA registry has more than one name | |
3674 | (alias), the name labeled as "(preferred MIME name)", if present, | |
3675 | MUST be used. | |
3676 | ||
3677 | The maximum length of 'charset' values used to represent IPP | |
3678 | attribute values is 63 octets. | |
3679 | ||
3680 | Some examples are: | |
3681 | ||
3682 | 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set | |
3683 | (UCS) represented as the UTF-8 [RFC2279] transfer encoding | |
3684 | scheme in which US-ASCII is a subset charset. | |
3685 | 'us-ascii': 7-bit American Standard Code for Information | |
3686 | Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard | |
3687 | defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the | |
3688 | control characters from conformant usage in MIME and IPP. | |
3689 | 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet | |
3690 | Nr 1 [ISO8859-1]. That standard defines a coded character set | |
3691 | that is used by Latin languages in the Western Hemisphere and | |
3692 | Western Europe. US-ASCII is a subset charset. | |
3693 | ||
3694 | ||
3695 | ||
3696 | ||
3697 | ||
3698 | deBry, et al. Experimental [Page 66] | |
3699 | \f | |
3700 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3701 | ||
3702 | ||
3703 | 'iso-10646-ucs-2': ISO 10646 Universal Multiple-Octet Coded | |
3704 | Character Set (UCS) represented as two octets (UCS-2), with the | |
3705 | high order octet of each pair coming first (so-called Big Endian | |
3706 | integer). | |
3707 | ||
3708 | Some attribute descriptions MAY place additional requirements on | |
3709 | charset values that may be used, such as REQUIRED values that MUST be | |
3710 | supported or additional restrictions, such as requiring that the | |
3711 | charset have US-ASCII as a subset charset. | |
3712 | ||
3713 | 4.1.8 'naturalLanguage' | |
3714 | ||
3715 | The 'naturalLanguage' attribute syntax is a standard identifier for a | |
3716 | natural language and optionally a country. The values for this | |
3717 | syntax type are defined by RFC 1766 [RFC1766]. Though RFC 1766 | |
3718 | requires that the values be case-insensitive US-ASCII, IPP requires | |
3719 | all lower case to simplify comparing by IPP clients and Printer | |
3720 | objects. Examples include: | |
3721 | ||
3722 | 'en': for English | |
3723 | 'en-us': for US English | |
3724 | 'fr': for French | |
3725 | 'de': for German | |
3726 | ||
3727 | The maximum length of 'naturalLanguage' values used to represent IPP | |
3728 | attribute values is 63 octets. | |
3729 | ||
3730 | 4.1.9 'mimeMediaType' | |
3731 | ||
3732 | The 'mimeMediaType' attribute syntax is the Internet Media Type | |
3733 | (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and | |
3734 | registered according to the procedures of RFC 2048 [RFC2048] for | |
3735 | identifying a document format. The value MAY include a charset | |
3736 | parameter, depending on the specification of the Media Type in the | |
3737 | IANA Registry [IANA-MT]. Although most other IPP syntax types allow | |
3738 | for only lower-cased values, this syntax type allows for mixed-case | |
3739 | values which are case-insensitive. | |
3740 | ||
3741 | Examples are: | |
3742 | ||
3743 | 'text/html': An HTML document | |
3744 | 'text/plain': A plain text document in US-ASCII (RFC 2046 indicates | |
3745 | that in the absence of the charset parameter MUST mean US-ASCII | |
3746 | rather than simply unspecified) [RFC2046]. | |
3747 | 'text/plain; charset=US-ASCII': A plain text document in US-ASCII | |
3748 | [52, 56]. | |
3749 | 'text/plain; charset=ISO-8859-1': A plain text document in ISO | |
3750 | 8859-1 (Latin 1) [ISO8859-1]. | |
3751 | ||
3752 | ||
3753 | ||
3754 | deBry, et al. Experimental [Page 67] | |
3755 | \f | |
3756 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3757 | ||
3758 | ||
3759 | 'text/plain; charset=utf-8': A plain text document in ISO 10646 | |
3760 | represented as UTF-8 [RFC2279] | |
3761 | 'text/plain, charset=iso-10646-ucs-2': A plain text document in | |
3762 | ISO 10646 represented in two octets (UCS-2) [ISO10646-1] | |
3763 | 'application/postscript': A PostScript document [RFC2046] | |
3764 | 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape | |
3765 | sequence embedded in the document data) | |
3766 | 'application/octet-stream': Auto-sense - see below | |
3767 | ||
3768 | One special type is 'application/octet-stream'. If the Printer | |
3769 | object supports this value, the Printer object MUST be capable of | |
3770 | auto-sensing the format of the document data. If the Printer | |
3771 | object's default value attribute "document-format-default" is set to | |
3772 | 'application/octet-stream', the Printer object not only supports | |
3773 | auto-sensing of the document format, but will depend on the result of | |
3774 | applying its auto-sensing when the client does not supply the | |
3775 | "document-format" attribute. If the client supplies a document | |
3776 | format value, the Printer MUST rely on the supplied attribute, rather | |
3777 | than trust its auto-sensing algorithm. To summarize: | |
3778 | ||
3779 | 1. If the client does not supply a document format value, the | |
3780 | Printer MUST rely on its default value setting (which may be ' | |
3781 | application/octet-stream' indicating an auto-sensing mechanism). | |
3782 | 2. If the client supplies a value other than 'application/octet- | |
3783 | stream', the client is supplying valid information about the | |
3784 | format of the document data and the Printer object MUST trust | |
3785 | the client supplied value more than the outcome of applying an | |
3786 | automatic format detection mechanism. For example, the client | |
3787 | may be requesting the printing of a PostScript file as a ' | |
3788 | text/plain' document. The Printer object MUST print a text | |
3789 | representation of the PostScript commands rather than interpret | |
3790 | the stream of PostScript commands and print the result. | |
3791 | 3. If the client supplies a value of 'application/octet-stream', | |
3792 | the client is indicating that the Printer object MUST use its | |
3793 | auto-sensing mechanism on the client supplied document data | |
3794 | whether auto-sensing is the Printer object's default or not. | |
3795 | ||
3796 | Note: Since the auto-sensing algorithm is probabilistic, if the | |
3797 | client requests both auto-sensing ("document-format" set to ' | |
3798 | application/octet-stream') and true fidelity ("ipp-attribute- | |
3799 | fidelity" set to 'true'), the Printer object might not be able to | |
3800 | guarantee exactly what the end user intended (the auto-sensing | |
3801 | algorithm might mistake one document format for another ), but it is | |
3802 | able to guarantee that its auto-sensing mechanism be used. | |
3803 | ||
3804 | The maximum length of a 'mimeMediaType' value to represent IPP | |
3805 | attribute values is 255 octets. | |
3806 | ||
3807 | ||
3808 | ||
3809 | ||
3810 | deBry, et al. Experimental [Page 68] | |
3811 | \f | |
3812 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3813 | ||
3814 | ||
3815 | 4.1.10 'octetString' | |
3816 | ||
3817 | The 'octetString' attribute syntax is a sequence of octets encoded in | |
3818 | a maximum of 1023 octets which is indicated in sub-section headers | |
3819 | using the notation: octetString(MAX). This syntax type is used for | |
3820 | opaque data. | |
3821 | ||
3822 | 4.1.11 'boolean' | |
3823 | ||
3824 | The 'boolean' attribute syntax has only two values: 'true' and ' | |
3825 | false'. | |
3826 | ||
3827 | 4.1.12 'integer' | |
3828 | ||
3829 | The 'integer' attribute syntax is an integer value that is in the | |
3830 | range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual | |
3831 | attribute may specify the range constraint explicitly in sub-section | |
3832 | headers if the range is different from the full range of possible | |
3833 | integer values. For example: job-priority (integer(1:100)) for the | |
3834 | "job-priority" attribute. However, the enforcement of that | |
3835 | additional constraint is up to the IPP objects, not the protocol. | |
3836 | ||
3837 | 4.1.13 'rangeOfInteger' | |
3838 | ||
3839 | The 'rangeOfInteger' attribute syntax is an ordered pair of integers | |
3840 | that defines an inclusive range of integer values. The first integer | |
3841 | specifies the lower bound and the second specifies the upper bound. | |
3842 | If a range constraint is specified in the header description for an | |
3843 | attribute in this document whose attribute syntax is 'rangeOfInteger' | |
3844 | (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum | |
3845 | value), then the constraint applies to both integers. | |
3846 | ||
3847 | 4.1.14 'dateTime' | |
3848 | ||
3849 | The 'dateTime' attribute syntax is a standard, fixed length, 11 octet | |
3850 | representation of the "DateAndTime" syntax as defined in RFC 2579 | |
3851 | [RFC2579]. RFC 2579 also identifies an 8 octet representation of a | |
3852 | "DateAndTime" value, but IPP objects MUST use the 11 octet | |
3853 | representation. A user interface will provide a mapping between | |
3854 | protocol dateTime values and displayable user-friendly words or | |
3855 | presentation values and phrases which are localized to the natural | |
3856 | language and date format of the user. | |
3857 | ||
3858 | 4.1.15 'resolution' | |
3859 | ||
3860 | The 'resolution' attribute syntax specifies a two-dimensional | |
3861 | resolution in the indicated units. It consists of 3 values: a cross | |
3862 | feed direction resolution (positive integer value), a feed direction | |
3863 | ||
3864 | ||
3865 | ||
3866 | deBry, et al. Experimental [Page 69] | |
3867 | \f | |
3868 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3869 | ||
3870 | ||
3871 | resolution (positive integer value), and a units value. The | |
3872 | semantics of these three components are taken from the Printer MIB | |
3873 | [RFC1759] suggested values. That is, the cross feed direction | |
3874 | component resolution component is the same as the | |
3875 | prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed | |
3876 | direction component resolution component is the same as the | |
3877 | prtMarkerAddressabilityFeedDir in the Printer MIB, and the units | |
3878 | component is the same as the prtMarkerAddressabilityUnit object in | |
3879 | the Printer MIB (namely, '3' indicates dots per inch and '4' | |
3880 | indicates dots per centimeter). All three values MUST be present | |
3881 | even if the first two values are the same. Example: '300', '600', ' | |
3882 | 3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi | |
3883 | feed direction resolution, since a '3' indicates dots per inch (dpi). | |
3884 | ||
3885 | 4.1.16 '1setOf X' | |
3886 | ||
3887 | The '1setOf X' attribute syntax is 1 or more values of attribute | |
3888 | syntax type X. This syntax type is used for multi-valued attributes. | |
3889 | The syntax type is called '1setOf' rather than just 'setOf' as a | |
3890 | reminder that the set of values MUST NOT be empty (i.e., a set of | |
3891 | size 0). Sets are normally unordered. However each attribute | |
3892 | description of this type may specify that the values MUST be in a | |
3893 | certain order for that attribute. | |
3894 | ||
3895 | 4.2 Job Template Attributes | |
3896 | ||
3897 | Job Template attributes describe job processing behavior. Support | |
3898 | for Job Template attributes by a Printer object is OPTIONAL (see | |
3899 | section 13.2.3 for a description of support for OPTIONAL attributes). | |
3900 | Also, clients OPTIONALLY supply Job Template attributes in create | |
3901 | requests. | |
3902 | ||
3903 | Job Template attributes conform to the following rules. For each Job | |
3904 | Template attribute called "xxx": | |
3905 | ||
3906 | 1. If the Printer object supports "xxx" then it MUST support both a | |
3907 | "xxx-default" attribute (unless there is a "No" in the table | |
3908 | below) and a "xxx-supported" attribute. If the Printer object | |
3909 | doesn't support "xxx", then it MUST support neither an "xxx- | |
3910 | default" attribute nor an "xxx-supported" attribute, and it MUST | |
3911 | treat an attribute "xxx" supplied by a client as unsupported. | |
3912 | An attribute "xxx" may be supported for some document formats | |
3913 | and not supported for other document formats. For example, it | |
3914 | is expected that a Printer object would only support | |
3915 | "orientation-requested" for some document formats (such as ' | |
3916 | text/plain' or 'text/html') but not others (such as ' | |
3917 | application/postscript'). | |
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | deBry, et al. Experimental [Page 70] | |
3923 | \f | |
3924 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3925 | ||
3926 | ||
3927 | 2. "xxx" is OPTIONALLY supplied by the client in a create request. | |
3928 | If "xxx" is supplied, the client is indicating a desired job | |
3929 | processing behavior for this Job. When "xxx" is not supplied, | |
3930 | the client is indicating that the Printer object apply its | |
3931 | default job processing behavior at job processing time if the | |
3932 | document content does not contain an embedded instruction | |
3933 | indicating an xxx-related behavior. | |
3934 | ||
3935 | Note: Since an administrator MAY change the default value | |
3936 | attribute after a Job object has been submitted but before it | |
3937 | has been processed, the default value used by the Printer object | |
3938 | at job processing time may be different that the default value | |
3939 | in effect at job submission time. | |
3940 | ||
3941 | 3. The "xxx-supported" attribute is a Printer object attribute that | |
3942 | describes which job processing behaviors are supported by that | |
3943 | Printer object. A client can query the Printer object to find | |
3944 | out what xxx-related behaviors are supported by inspecting the | |
3945 | returned values of the "xxx-supported" attribute. | |
3946 | ||
3947 | Note: The "xxx" in each "xxx-supported" attribute name is | |
3948 | singular, even though an "xxx-supported" attribute usually has | |
3949 | more than one value, such as "job-sheet-supported", unless the | |
3950 | "xxx" Job Template attribute is plural, such as "finishings" or | |
3951 | "sides". In such cases the "xxx-supported" attribute names are: | |
3952 | "finishings-supported" and "sides-supported". | |
3953 | ||
3954 | 4. The "xxx-default" default value attribute describes what will be | |
3955 | done at job processing time when no other job processing | |
3956 | information is supplied by the client (either explicitly as an | |
3957 | IPP attribute in the create request or implicitly as an embedded | |
3958 | instruction within the document data). | |
3959 | ||
3960 | If an application wishes to present an end user with a list of | |
3961 | supported values from which to choose, the application SHOULD query | |
3962 | the Printer object for its supported value attributes. The | |
3963 | application SHOULD also query the default value attributes. If the | |
3964 | application then limits selectable values to only those value that | |
3965 | are supported, the application can guarantee that the values supplied | |
3966 | by the client in the create request all fall within the set of | |
3967 | supported values at the Printer. When querying the Printer, the | |
3968 | client MAY enumerate each attribute by name in the Get-Printer- | |
3969 | Attributes Request, or the client MAY just name the "job-template" | |
3970 | group in order to get the complete set of supported attributes (both | |
3971 | supported and default attributes). | |
3972 | ||
3973 | ||
3974 | ||
3975 | ||
3976 | ||
3977 | ||
3978 | deBry, et al. Experimental [Page 71] | |
3979 | \f | |
3980 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
3981 | ||
3982 | ||
3983 | The "finishings" attribute is an example of a Job Template attribute. | |
3984 | It can take on a set of values such as 'staple', 'punch', and/or ' | |
3985 | cover'. A client can query the Printer object for the "finishings- | |
3986 | supported" attribute and the "finishings-default" attribute. The | |
3987 | supported attribute contains a set of supported values. The default | |
3988 | value attribute contains the finishing value(s) that will be used for | |
3989 | a new Job if the client does not supply a "finishings" attribute in | |
3990 | the create request and the document data does not contain any | |
3991 | corresponding finishing instructions. If the client does supply the | |
3992 | "finishings" attribute in the create request, the IPP object | |
3993 | validates the value or values to make sure that they are a subset of | |
3994 | the supported values identified in the Printer object's "finishings- | |
3995 | supported" attribute. See section 3.2.1.2. | |
3996 | ||
3997 | The table below summarizes the names and relationships for all Job | |
3998 | Template attributes. The first column of the table (labeled "Job | |
3999 | Attribute") shows the name and syntax for each Job Template attribute | |
4000 | in the Job object. These are the attributes that can optionally be | |
4001 | supplied by the client in a create request. The last two columns | |
4002 | (labeled "Printer: Default Value Attribute" and "Printer: Supported | |
4003 | Values Attribute") shows the name and syntax for each Job Template | |
4004 | attribute in the Printer object (the default value attribute and the | |
4005 | supported values attribute). A "No" in the table means the Printer | |
4006 | MUST NOT support the attribute (that is, the attribute is simply not | |
4007 | applicable). For brevity in the table, the 'text' and 'name' entries | |
4008 | do not show the maximum length for each attribute. | |
4009 | ||
4010 | +===================+======================+======================+ | |
4011 | | Job Attribute |Printer: Default Value| Printer: Supported | | |
4012 | | | Attribute | Values Attribute | | |
4013 | +===================+======================+======================+ | |
4014 | | job-priority | job-priority-default |job-priority-supported| | |
4015 | | (integer 1:100) | (integer 1:100) |(integer 1:100) | | |
4016 | +-------------------+----------------------+----------------------+ | |
4017 | | job-hold-until | job-hold-until- |job-hold-until- | | |
4018 | | (type3 keyword | | default | supported | | |
4019 | | name) | (type3 keyword | |(1setOf | | |
4020 | | | name) | type3 keyword | name)| | |
4021 | +-------------------+----------------------+----------------------+ | |
4022 | | job-sheets | job-sheets-default |job-sheets-supported | | |
4023 | | (type3 keyword | | (type3 keyword | |(1setOf | | |
4024 | | name) | name) | type3 keyword | name)| | |
4025 | +-------------------+----------------------+----------------------+ | |
4026 | |multiple-document- |multiple-document- |multiple-document- | | |
4027 | | handling | handling-default |handling-supported | | |
4028 | | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)| | |
4029 | +-------------------+----------------------+----------------------+ | |
4030 | ||
4031 | ||
4032 | ||
4033 | ||
4034 | deBry, et al. Experimental [Page 72] | |
4035 | \f | |
4036 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4037 | ||
4038 | ||
4039 | +===================+======================+======================+ | |
4040 | | Job Attribute |Printer: Default Value| Printer: Supported | | |
4041 | | | Attribute | Values Attribute | | |
4042 | +===================+======================+======================+ | |
4043 | | copies | copies-default | copies-supported | | |
4044 | | (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger | | |
4045 | | | | (1:MAX)) | | |
4046 | +-------------------+----------------------+----------------------+ | |
4047 | | finishings | finishings-default | finishings-supported | | |
4048 | |(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) | | |
4049 | +-------------------+----------------------+----------------------+ | |
4050 | | page-ranges | No | page-ranges- | | |
4051 | | (1setOf | | supported (boolean) | | |
4052 | | rangeOfInteger | | | | |
4053 | | (1:MAX)) | | | | |
4054 | +-------------------+----------------------+----------------------+ | |
4055 | | sides | sides-default | sides-supported | | |
4056 | | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)| | |
4057 | +-------------------+----------------------+----------------------+ | |
4058 | | number-up | number-up-default | number-up-supported | | |
4059 | | (integer (1:MAX)) | (integer (1:MAX)) |(1setOf integer | | |
4060 | | | | (1:MAX) | | | |
4061 | | | | rangeOfInteger | | |
4062 | | | | (1:MAX)) | | |
4063 | +-------------------+----------------------+----------------------+ | |
4064 | | orientation- |orientation-requested-|orientation-requested-| | |
4065 | | requested | default | supported | | |
4066 | | (type2 enum) | (type2 enum) | (1setOf type2 enum) | | |
4067 | +-------------------+----------------------+----------------------+ | |
4068 | | media | media-default | media-supported | | |
4069 | | (type3 keyword | | (type3 keyword | |(1setOf | | |
4070 | | name) | name) | type3 keyword | name)| | |
4071 | | | | | | |
4072 | | | | media-ready | | |
4073 | | | |(1setOf | | |
4074 | | | | type3 keyword | name)| | |
4075 | +-------------------+----------------------+----------------------+ | |
4076 | | printer-resolution| printer-resolution- | printer-resolution- | | |
4077 | | (resolution) | default | supported | | |
4078 | | | (resolution) |(1setOf resolution) | | |
4079 | +-------------------+----------------------+----------------------+ | |
4080 | | print-quality | print-quality-default| print-quality- | | |
4081 | | (type2 enum) | (type2 enum) | supported | | |
4082 | | | |(1setOf type2 enum) | | |
4083 | +-------------------+----------------------+----------------------+ | |
4084 | ||
4085 | ||
4086 | ||
4087 | ||
4088 | ||
4089 | ||
4090 | deBry, et al. Experimental [Page 73] | |
4091 | \f | |
4092 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4093 | ||
4094 | ||
4095 | 4.2.1 job-priority (integer(1:100)) | |
4096 | ||
4097 | This attribute specifies a priority for scheduling the Job. A higher | |
4098 | value specifies a higher priority. The value 1 indicates the lowest | |
4099 | possible priority. The value 100 indicates the highest possible | |
4100 | priority. Among those jobs that are ready to print, a Printer MUST | |
4101 | print all jobs with a priority value of n before printing those with | |
4102 | a priority value of n-1 for all n. | |
4103 | ||
4104 | If the Printer object supports this attribute, it MUST always support | |
4105 | the full range from 1 to 100. No administrative restrictions are | |
4106 | permitted. This way an end-user can always make full use of the | |
4107 | entire range with any Printer object. If privileged jobs are | |
4108 | implemented outside IPP/1.0, they MUST have priorities higher than | |
4109 | 100, rather than restricting the range available to end-users. | |
4110 | ||
4111 | If the client does not supply this attribute and this attribute is | |
4112 | supported by the Printer object, the Printer object MUST use the | |
4113 | value of the Printer object's "job-priority-default" at job | |
4114 | submission time (unlike most Job Template attributes that are used if | |
4115 | necessary at job processing time). | |
4116 | ||
4117 | The syntax for the "job-priority-supported" is also integer(1:100). | |
4118 | This single integer value indicates the number of priority levels | |
4119 | supported. The Printer object MUST take the value supplied by the | |
4120 | client and map it to the closest integer in a sequence of n integers | |
4121 | values that are evenly distributed over the range from 1 to 100 using | |
4122 | the formula: | |
4123 | ||
4124 | roundToNearestInt((100x+50)/n) | |
4125 | ||
4126 | where n is the value of "job-priority-supported" and x ranges from 0 | |
4127 | through n-1. | |
4128 | ||
4129 | For example, if n=1 the sequence of values is 50; if n=2, the | |
4130 | sequence of values is: 25 and 75; if n = 3, the sequence of values | |
4131 | is: 17, 50 and 83; if n = 10, the sequence of values is: 5, 15, 25, | |
4132 | 35, 45, 55, 65, 75, 85, and 95; if n = 100, the sequence of values | |
4133 | is: 1, 2, 3, . 100. | |
4134 | ||
4135 | If the value of the Printer object's "job-priority-supported" is 10 | |
4136 | and the client supplies values in the range 1 to 10, the Printer | |
4137 | object maps them to 5, in the range 11 to 20, the Printer object maps | |
4138 | them to 15, etc. | |
4139 | ||
4140 | ||
4141 | ||
4142 | ||
4143 | ||
4144 | ||
4145 | ||
4146 | deBry, et al. Experimental [Page 74] | |
4147 | \f | |
4148 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4149 | ||
4150 | ||
4151 | 4.2.2 job-hold-until (type3 keyword | name (MAX)) | |
4152 | ||
4153 | This attribute specifies the named time period during which the Job | |
4154 | MUST become a candidate for printing. | |
4155 | ||
4156 | Standard keyword values for named time periods are: | |
4157 | ||
4158 | 'no-hold': immediately, if there are not other reasons to hold the | |
4159 | job | |
4160 | 'day-time': during the day | |
4161 | 'evening': evening | |
4162 | 'night': night | |
4163 | 'weekend': weekend | |
4164 | 'second-shift': second-shift (after close of business) | |
4165 | 'third-shift': third-shift (after midnight) | |
4166 | ||
4167 | An administrator MUST associate allowable print times with a named | |
4168 | time period (by means outside IPP/1.0). An administrator is | |
4169 | encouraged to pick names that suggest the type of time period. An | |
4170 | administrator MAY define additional values using the 'name' or ' | |
4171 | keyword' attribute syntax, depending on implementation. | |
4172 | ||
4173 | If the value of this attribute specifies a time period that is in the | |
4174 | future, the Printer MUST add the 'job-hold-until-specified' value to | |
4175 | the job's "job-state-reasons" attribute, move the job to the ' | |
4176 | pending-held' state, and MUST NOT schedule the job for printing until | |
4177 | the specified time-period arrives. When the specified time period | |
4178 | arrives, the Printer MUST remove the 'job-hold-until-specified' value | |
4179 | from the job's "job-state-reason" attribute and, if there are no | |
4180 | other job state reasons that keep the job in the 'pending-held' | |
4181 | state, the Printer MUST consider the job as a candidate for | |
4182 | processing by moving the job to the 'pending' state. | |
4183 | ||
4184 | If this job attribute value is the named value 'no-hold', or the | |
4185 | specified time period has already started, the job MUST be a | |
4186 | candidate for processing immediately. | |
4187 | ||
4188 | If the client does not supply this attribute and this attribute is | |
4189 | supported by the Printer object, the Printer object MUST use the | |
4190 | value of the Printer object's "job-hold-until-default" at job | |
4191 | submission time (unlike most Job Template attributes that are used if | |
4192 | necessary at job processing time). | |
4193 | ||
4194 | 4.2.3 job-sheets (type3 keyword | name(MAX)) | |
4195 | ||
4196 | This attribute determines which job start/end sheet(s), if any, MUST | |
4197 | be printed with a job. | |
4198 | ||
4199 | ||
4200 | ||
4201 | ||
4202 | deBry, et al. Experimental [Page 75] | |
4203 | \f | |
4204 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4205 | ||
4206 | ||
4207 | Standard keyword values are: | |
4208 | ||
4209 | 'none': no job sheet is printed | |
4210 | 'standard': one or more site specific standard job sheets are | |
4211 | printed, e.g. a single start sheet or both start and end sheet | |
4212 | is printed | |
4213 | ||
4214 | An administrator MAY define additional values using the 'name' or ' | |
4215 | keyword' attribute syntax, depending on implementation. | |
4216 | ||
4217 | Note: The effect of this attribute on jobs with multiple documents | |
4218 | MAY be affected by the "multiple-document-handling" job attribute | |
4219 | (section 4.2.4), depending on the job sheet semantics. | |
4220 | ||
4221 | 4.2.4 multiple-document-handling (type2 keyword) | |
4222 | ||
4223 | This attribute is relevant only if a job consists of two or more | |
4224 | documents. The attribute controls finishing operations and the | |
4225 | placement of one or more print-stream pages into impressions and onto | |
4226 | media sheets. When the value of the "copies" attribute exceeds 1, it | |
4227 | also controls the order in which the copies that result from | |
4228 | processing the documents are produced. For the purposes of this | |
4229 | explanations, if "a" represents an instance of document data, then | |
4230 | the result of processing the data in document "a" is a sequence of | |
4231 | media sheets represented by "a(*)". | |
4232 | ||
4233 | Standard keyword values are: | |
4234 | ||
4235 | 'single-document': If a Job object has multiple documents, say, the | |
4236 | document data is called a and b, then the result of processing | |
4237 | all the document data (a and then b) MUST be treated as a single | |
4238 | sequence of media sheets for finishing operations; that is, | |
4239 | finishing would be performed on the concatenation of the | |
4240 | sequences a(*),b(*). The Printer object MUST NOT force the data | |
4241 | in each document instance to be formatted onto a new print- | |
4242 | stream page, nor to start a new impression on a new media sheet. | |
4243 | If more than one copy is made, the ordering of the sets of media | |
4244 | sheets resulting from processing the document data MUST be a(*), | |
4245 | b(*), a(*), b(*), ..., and the Printer object MUST force each | |
4246 | copy (a(*),b(*)) to start on a new media sheet. | |
4247 | 'separate-documents-uncollated-copies': If a Job object has | |
4248 | multiple documents, say, the document data is called a and b, | |
4249 | then the result of processing the data in each document instance | |
4250 | MUST be treated as a single sequence of media sheets for | |
4251 | finishing operations; that is, the sets a(*) and b(*) would each | |
4252 | be finished separately. The Printer object MUST force each copy | |
4253 | of the result of processing the data in a single document to | |
4254 | start on a new media sheet. If more than one copy is made, the | |
4255 | ||
4256 | ||
4257 | ||
4258 | deBry, et al. Experimental [Page 76] | |
4259 | \f | |
4260 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4261 | ||
4262 | ||
4263 | ordering of the sets of media sheets resulting from processing | |
4264 | the document data MUST be a(*), a(*), ..., b(*), b(*) ... . | |
4265 | 'separate-documents-collated-copies': If a Job object has multiple | |
4266 | documents, say, the document data is called a and b, then the | |
4267 | result of processing the data in each document instance MUST be | |
4268 | treated as a single sequence of media sheets for finishing | |
4269 | operations; that is, the sets a(*) and b(*) would each be | |
4270 | finished separately. The Printer object MUST force each copy of | |
4271 | the result of processing the data in a single document to start | |
4272 | on a new media sheet. If more than one copy is made, the | |
4273 | ordering of the sets of media sheets resulting from processing | |
4274 | the document data MUST be a(*), b(*), a(*), b(*), ... . | |
4275 | 'single-document-new-sheet': Same as 'single-document', except | |
4276 | that the Printer object MUST ensure that the first impression of | |
4277 | each document instance in the job is placed on a new media | |
4278 | sheet. This value allows multiple documents to be stapled | |
4279 | together with a single staple where each document starts on a | |
4280 | new sheet. | |
4281 | ||
4282 | The 'single-document' value is the same as 'separate-documents- | |
4283 | collated-copies' with respect to ordering of print-stream pages, but | |
4284 | not media sheet generation, since 'single-document' will put the | |
4285 | first page of the next document on the back side of a sheet if an odd | |
4286 | number of pages have been produced so far for the job, while ' | |
4287 | separate-documents-collated-copies' always forces the next document | |
4288 | or document copy on to a new sheet. In addition, if the "finishings" | |
4289 | attribute specifies 'staple', then with 'single-document', documents | |
4290 | a and b are stapled together as a single document with no regard to | |
4291 | new sheets, with 'single-document-new-sheet', documents a and b are | |
4292 | stapled together as a single document, but document b starts on a new | |
4293 | sheet, but with 'separate-documents-uncollated-copies' and ' | |
4294 | separate-documents-collated-copies', documents a and b are stapled | |
4295 | separately. | |
4296 | ||
4297 | Note: None of these values provide means to produce uncollated sheets | |
4298 | within a document, i.e., where multiple copies of sheet n are | |
4299 | produced before sheet n+1 of the same document. | |
4300 | ||
4301 | The relationship of this attribute and the other attributes that | |
4302 | control document processing is described in section 15.3. | |
4303 | ||
4304 | 4.2.5 copies (integer(1:MAX)) | |
4305 | ||
4306 | This attribute specifies the number of copies to be printed. | |
4307 | ||
4308 | On many devices the supported number of collated copies will be | |
4309 | limited by the number of physical output bins on the device, and may | |
4310 | be different from the number of uncollated copies which can be | |
4311 | ||
4312 | ||
4313 | ||
4314 | deBry, et al. Experimental [Page 77] | |
4315 | \f | |
4316 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4317 | ||
4318 | ||
4319 | supported. | |
4320 | ||
4321 | Note: The effect of this attribute on jobs with multiple documents is | |
4322 | controlled by the "multiple-document-handling" job attribute (section | |
4323 | 4.2.4) and the relationship of this attribute and the other | |
4324 | attributes that control document processing is described in section | |
4325 | 15.3. | |
4326 | ||
4327 | 4.2.6 finishings (1setOf type2 enum) | |
4328 | ||
4329 | This attribute identifies the finishing operations that the Printer | |
4330 | uses for each copy of each printed document in the Job. For Jobs with | |
4331 | multiple documents, the "multiple-document-handling" attribute | |
4332 | determines what constitutes a "copy" for purposes of finishing. | |
4333 | ||
4334 | Standard enum values are: | |
4335 | ||
4336 | Value Symbolic Name and Description | |
4337 | ||
4338 | '3' 'none': Perform no finishing | |
4339 | '4' 'staple': Bind the document(s) with one or more staples. | |
4340 | The exact number and placement of the staples is | |
4341 | site-defined. | |
4342 | '5' 'punch': This value indicates that holes are required in | |
4343 | the finished document. The exact number and placement | |
4344 | of the holes is site-defined The punch specification | |
4345 | MAY be satisfied (in a site- and implementation- | |
4346 | specific manner) either by drilling/punching, or by | |
4347 | substituting pre-drilled media. | |
4348 | '6' 'cover': This value is specified when it is desired to | |
4349 | select a non-printed (or pre-printed) cover for the | |
4350 | document. This does not supplant the specification of | |
4351 | a printed cover (on cover stock medium) by the | |
4352 | document itself. | |
4353 | '7' 'bind': This value indicates that a binding is to be | |
4354 | applied to the document; the type and placement of the | |
4355 | binding is site-defined." | |
4356 | ||
4357 | Note: The effect of this attribute on jobs with multiple documents is | |
4358 | controlled by the "multiple-document-handling" job attribute (section | |
4359 | 4.2.4) and the relationship of this attribute and the other | |
4360 | attributes that control document processing is described in section | |
4361 | 15.3. | |
4362 | ||
4363 | If the client supplies a value of 'none' along with any other | |
4364 | combination of values, it is the same as if only that other | |
4365 | combination of values had been supplied (that is the 'none' value has | |
4366 | no effect). | |
4367 | ||
4368 | ||
4369 | ||
4370 | deBry, et al. Experimental [Page 78] | |
4371 | \f | |
4372 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4373 | ||
4374 | ||
4375 | 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) | |
4376 | ||
4377 | This attribute identifies the range(s) of print-stream pages that the | |
4378 | Printer object uses for each copy of each document which are to be | |
4379 | printed. Nothing is printed for any pages identified that do not | |
4380 | exist in the document(s). Ranges MUST be in ascending order, for | |
4381 | example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling | |
4382 | Printer object can process the job in a single pass. If the ranges | |
4383 | are not ascending or are overlapping, the IPP object MUST reject the | |
4384 | request and return the 'client-error-bad-request' status code. The | |
4385 | attribute is associated with print-stream pages not application- | |
4386 | numbered pages (for example, the page numbers found in the headers | |
4387 | and or footers for certain word processing applications). | |
4388 | ||
4389 | For Jobs with multiple documents, the "multiple-document-handling" | |
4390 | attribute determines what constitutes a "copy" for purposes of the | |
4391 | specified page range(s). When "multiple-document-handling" is ' | |
4392 | single-document', the Printer object MUST apply each supplied page | |
4393 | range once to the concatenation of the print-stream pages. For | |
4394 | example, if there are 8 documents of 10 pages each, the page-range ' | |
4395 | 41:60' prints the pages in the 5th and 6th documents as a single | |
4396 | document and none of the pages of the other documents are printed. | |
4397 | When "multiple-document-handling" is 'separate-documents-uncollated- | |
4398 | copies' or 'separate-documents-collated-copies', the Printer object | |
4399 | MUST apply each supplied page range repeatedly to each document copy. | |
4400 | For the same job, the page-range '1:3, 10:10' would print the first 3 | |
4401 | pages and the 10th page of each of the 8 documents in the Job, as 8 | |
4402 | separate documents. | |
4403 | ||
4404 | In most cases, the exact pages to be printed will be generated by a | |
4405 | device driver and this attribute would not be required. However, | |
4406 | when printing an archived document which has already been formatted, | |
4407 | the end user may elect to print just a subset of the pages contained | |
4408 | in the document. In this case, if page-range = n.m is specified, the | |
4409 | first page to be printed will be page n. All subsequent pages of the | |
4410 | document will be printed through and including page m. | |
4411 | ||
4412 | "page-ranges-supported" is a boolean value indicating whether or not | |
4413 | the printer is capable of supporting the printing of page ranges. | |
4414 | This capability may differ from one PDL to another. There is no | |
4415 | "page-ranges-default" attribute. If the "page-ranges" attribute is | |
4416 | not supplied by the client, all pages of the document will be | |
4417 | printed. | |
4418 | ||
4419 | ||
4420 | ||
4421 | ||
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | deBry, et al. Experimental [Page 79] | |
4427 | \f | |
4428 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4429 | ||
4430 | ||
4431 | Note: The effect of this attribute on jobs with multiple documents is | |
4432 | controlled by the "multiple-document-handling" job attribute (section | |
4433 | 4.2.4) and the relationship of this attribute and the other | |
4434 | attributes that control document processing is described in section | |
4435 | 15.3. | |
4436 | ||
4437 | 4.2.8 sides (type2 keyword) | |
4438 | ||
4439 | This attribute specifies how print-stream pages are to be imposed | |
4440 | upon the sides of an instance of a selected medium, i.e., an | |
4441 | impression. | |
4442 | ||
4443 | The standard keyword values are: | |
4444 | ||
4445 | 'one-sided': imposes each consecutive print-stream page upon the | |
4446 | same side of consecutive media sheets. | |
4447 | 'two-sided-long-edge': imposes each consecutive pair of print- | |
4448 | stream pages upon front and back sides of consecutive media | |
4449 | sheets, such that the orientation of each pair of print-stream | |
4450 | pages on the medium would be correct for the reader as if for | |
4451 | binding on the long edge. This imposition is sometimes called ' | |
4452 | duplex' or 'head-to-head'. | |
4453 | 'two-sided-short-edge': imposes each consecutive pair of print- | |
4454 | stream pages upon front and back sides of consecutive media | |
4455 | sheets, such that the orientation of each pair of print-stream | |
4456 | pages on the medium would be correct for the reader as if for | |
4457 | binding on the short edge. This imposition is sometimes called | |
4458 | 'tumble' or 'head-to-toe'. | |
4459 | ||
4460 | 'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex' | |
4461 | all work the same for portrait or landscape. However 'head-to-toe' | |
4462 | is 'tumble' in portrait but 'duplex' in landscape. 'head-to-head' | |
4463 | also switches between 'duplex' and 'tumble' when using portrait and | |
4464 | landscape modes. | |
4465 | ||
4466 | Note: The effect of this attribute on jobs with multiple documents is | |
4467 | controlled by the "multiple-document-handling" job attribute (section | |
4468 | 4.2.4) and the relationship of this attribute and the other | |
4469 | attributes that control document processing is described in section | |
4470 | 15.3. | |
4471 | ||
4472 | 4.2.9 number-up (integer(1:MAX)) | |
4473 | ||
4474 | This attribute specifies the number of print-stream pages to impose | |
4475 | upon a single side of an instance of a selected medium. For example, | |
4476 | if the value is: | |
4477 | ||
4478 | ||
4479 | ||
4480 | ||
4481 | ||
4482 | deBry, et al. Experimental [Page 80] | |
4483 | \f | |
4484 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4485 | ||
4486 | ||
4487 | Value Description | |
4488 | ||
4489 | '1' the Printer MUST place one print-stream page on a single | |
4490 | side of an instance of the selected medium (MAY add | |
4491 | some sort of translation, scaling, or rotation). | |
4492 | '2' the Printer MUST place two print-stream pages on a single | |
4493 | side of an instance of the selected medium (MAY add | |
4494 | some sort of translation, scaling, or rotation). | |
4495 | '4' the Printer MUST place four print-stream pages on a single | |
4496 | side of an instance of the selected medium (MAY add | |
4497 | some sort of translation, scaling, or rotation). | |
4498 | ||
4499 | This attribute primarily controls the translation, scaling and | |
4500 | rotation of print-stream pages. | |
4501 | ||
4502 | Note: The effect of this attribute on jobs with multiple documents is | |
4503 | controlled by the "multiple-document-handling" job attribute (section | |
4504 | 4.2.4) and the relationship of this attribute and the other | |
4505 | attributes that control document processing is described in section | |
4506 | 15.3. | |
4507 | ||
4508 | 4.2.10 orientation-requested (type2 enum) | |
4509 | ||
4510 | This attribute indicates the desired orientation for printed print- | |
4511 | stream pages; it does not describe the orientation of the client- | |
4512 | supplied print-stream pages. | |
4513 | ||
4514 | For some document formats (such as 'application/postscript'), the | |
4515 | desired orientation of the print-stream pages is specified within the | |
4516 | document data. This information is generated by a device driver | |
4517 | prior to the submission of the print job. Other document formats | |
4518 | (such as 'text/plain') do not include the notion of desired | |
4519 | orientation within the document data. In the latter case it is | |
4520 | possible for the Printer object to bind the desired orientation to | |
4521 | the document data after it has been submitted. It is expected that a | |
4522 | Printer object would only support "orientations-requested" for some | |
4523 | document formats (e.g., 'text/plain' or 'text/html') but not others | |
4524 | (e.g., 'application/postscript'). This is no different than any | |
4525 | other Job Template attribute since section 4.2, item 1, points out | |
4526 | that a Printer object may support or not support any Job Template | |
4527 | attribute based on the document format supplied by the client. | |
4528 | However, a special mention is made here since it is very likely that | |
4529 | a Printer object will support "orientation-requested" for only a | |
4530 | subset of the supported document formats. | |
4531 | ||
4532 | ||
4533 | ||
4534 | ||
4535 | ||
4536 | ||
4537 | ||
4538 | deBry, et al. Experimental [Page 81] | |
4539 | \f | |
4540 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4541 | ||
4542 | ||
4543 | Standard enum values are: | |
4544 | ||
4545 | Value Symbolic Name and Description | |
4546 | ||
4547 | '3' 'portrait': The content will be imaged across the short | |
4548 | edge of the medium. | |
4549 | '4' 'landscape': The content will be imaged across the long | |
4550 | edge of the medium. Landscape is defined to be a | |
4551 | rotation of the print-stream page to be imaged by +90 | |
4552 | degrees with respect to the medium (i.e. anti- | |
4553 | clockwise) from the portrait orientation. Note: The | |
4554 | +90 direction was chosen because simple finishing on | |
4555 | the long edge is the same edge whether portrait or | |
4556 | landscape | |
4557 | '5' 'reverse-landscape': The content will be imaged across the | |
4558 | long edge of the medium. Reverse-landscape is defined | |
4559 | to be a rotation of the print-stream page to be imaged | |
4560 | by - 90 degrees with respect to the medium (i.e. | |
4561 | clockwise) from the portrait orientation. Note: The ' | |
4562 | reverse-landscape' value was added because some | |
4563 | applications rotate landscape -90 degrees from | |
4564 | portrait, rather than +90 degrees. | |
4565 | '6' 'reverse-portrait': The content will be imaged across the | |
4566 | short edge of the medium. Reverse-portrait is defined | |
4567 | to be a rotation of the print-stream page to be imaged | |
4568 | by 180 degrees with respect to the medium from the | |
4569 | portrait orientation. Note: The 'reverse-portrait' | |
4570 | value was added for use with the "finishings" | |
4571 | attribute in cases where the opposite edge is desired | |
4572 | for finishing a portrait document on simple finishing | |
4573 | devices that have only one finishing position. Thus a | |
4574 | 'text'/plain' portrait document can be stapled "on the | |
4575 | right" by a simple finishing device as is common use | |
4576 | with some middle eastern languages such as Hebrew. | |
4577 | ||
4578 | Note: The effect of this attribute on jobs with multiple documents is | |
4579 | controlled by the "multiple-document-handling" job attribute (section | |
4580 | 4.2.4) and the relationship of this attribute and the other | |
4581 | attributes that control document processing is described in section | |
4582 | 15.3. | |
4583 | ||
4584 | 4.2.11 media (type3 keyword | name(MAX)) | |
4585 | ||
4586 | This attribute identifies the medium that the Printer uses for all | |
4587 | impressions of the Job. | |
4588 | ||
4589 | The values for "media" include medium-names, medium-sizes, input- | |
4590 | trays and electronic forms so that one attribute specifies the media. | |
4591 | ||
4592 | ||
4593 | ||
4594 | deBry, et al. Experimental [Page 82] | |
4595 | \f | |
4596 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4597 | ||
4598 | ||
4599 | If a Printer object supports a medium name as a value of this | |
4600 | attribute, such a medium name implicitly selects an input-tray that | |
4601 | contains the specified medium. If a Printer object supports a medium | |
4602 | size as a value of this attribute, such a medium size implicitly | |
4603 | selects a medium name that in turn implicitly selects an input-tray | |
4604 | that contains the medium with the specified size. If a Printer | |
4605 | object supports an input-tray as the value of this attribute, such an | |
4606 | input-tray implicitly selects the medium that is in that input-tray | |
4607 | at the time the job prints. This case includes manual-feed input- | |
4608 | trays. If a Printer object supports an electronic form as the value | |
4609 | of this attribute, such an electronic form implicitly selects a | |
4610 | medium-name that in turn implicitly selects an input-tray that | |
4611 | contains the medium specified by the electronic form. The electronic | |
4612 | form also implicitly selects an image that the Printer MUST merge | |
4613 | with the document data as its prints each page. | |
4614 | ||
4615 | Standard keyword values are (taken from ISO DPA and the Printer MIB) | |
4616 | and are listed in section 14. An administrator MAY define additional | |
4617 | values using the 'name' or 'keyword' attribute syntax, depending on | |
4618 | implementation. | |
4619 | ||
4620 | There is also an additional Printer attribute named "media-ready" | |
4621 | which differs from "media-supported" in that legal values only | |
4622 | include the subset of "media-supported" values that are physically | |
4623 | loaded and ready for printing with no operator intervention required. | |
4624 | If an IPP object supports "media-supported", it NEED NOT support | |
4625 | "media-ready". | |
4626 | ||
4627 | The relationship of this attribute and the other attributes that | |
4628 | control document processing is described in section 15.3. | |
4629 | ||
4630 | 4.2.12 printer-resolution (resolution) | |
4631 | ||
4632 | This attribute identifies the resolution that Printer uses for the | |
4633 | Job. | |
4634 | ||
4635 | 4.2.13 print-quality (type2 enum) | |
4636 | ||
4637 | This attribute specifies the print quality that the Printer uses for | |
4638 | the Job. | |
4639 | ||
4640 | The standard enum values are: | |
4641 | ||
4642 | Value Symbolic Name and Description | |
4643 | ||
4644 | '3' 'draft': lowest quality available on the printer | |
4645 | '4' 'normal': normal or intermediate quality on the printer | |
4646 | '5' 'high': highest quality available on the printer | |
4647 | ||
4648 | ||
4649 | ||
4650 | deBry, et al. Experimental [Page 83] | |
4651 | \f | |
4652 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4653 | ||
4654 | ||
4655 | 4.3 Job Description Attributes | |
4656 | ||
4657 | The attributes in this section form the attribute group called "job- | |
4658 | description". The following table summarizes these attributes. The | |
4659 | third column indicates whether the attribute is a REQUIRED attribute | |
4660 | that MUST be supported by Printer objects. If it is not indicated as | |
4661 | REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text' | |
4662 | and 'name' attributes is indicated in parenthesizes. | |
4663 | ||
4664 | +----------------------------+----------------------+----------------+ | |
4665 | | Attribute | Syntax | REQUIRED? | | |
4666 | +----------------------------+----------------------+----------------+ | |
4667 | | job-uri | uri | REQUIRED | | |
4668 | +----------------------------+----------------------+----------------+ | |
4669 | | job-id | integer(1:MAX) | REQUIRED | | |
4670 | +----------------------------+----------------------+----------------+ | |
4671 | | job-printer-uri | uri | REQUIRED | | |
4672 | +----------------------------+----------------------+----------------+ | |
4673 | | job-more-info | uri | | | |
4674 | +----------------------------+----------------------+----------------+ | |
4675 | | job-name | name (MAX) | REQUIRED | | |
4676 | +----------------------------+----------------------+----------------+ | |
4677 | | job-originating-user-name | name (MAX) | REQUIRED | | |
4678 | +----------------------------+----------------------+----------------+ | |
4679 | | job-state | type1 enum | REQUIRED | | |
4680 | +----------------------------+----------------------+----------------+ | |
4681 | | job-state-reasons | 1setOf type2 keyword | | | |
4682 | +----------------------------+----------------------+----------------+ | |
4683 | | job-state-message | text (MAX) | | | |
4684 | +----------------------------+----------------------+----------------+ | |
4685 | | number-of-documents | integer (0:MAX) | | | |
4686 | +----------------------------+----------------------+----------------+ | |
4687 | | output-device-assigned | name (127) | | | |
4688 | +----------------------------+----------------------+----------------+ | |
4689 | | time-at-creation | integer (0:MAX) | | | |
4690 | +----------------------------+----------------------+----------------+ | |
4691 | | time-at-processing | integer (0:MAX) | | | |
4692 | +----------------------------+----------------------+----------------+ | |
4693 | | time-at-completed | integer (0:MAX) | | | |
4694 | +----------------------------+----------------------+----------------+ | |
4695 | | number-of-intervening-jobs | integer (0:MAX) | | | |
4696 | +----------------------------+----------------------+----------------+ | |
4697 | | job-message-from-operator | text (127) | | | |
4698 | +----------------------------+----------------------+----------------+ | |
4699 | | job-k-octets | integer (0:MAX) | | | |
4700 | +----------------------------+----------------------+----------------+ | |
4701 | | job-impressions | integer (0:MAX) | | | |
4702 | +----------------------------+----------------------+----------------+ | |
4703 | ||
4704 | ||
4705 | ||
4706 | deBry, et al. Experimental [Page 84] | |
4707 | \f | |
4708 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4709 | ||
4710 | ||
4711 | +----------------------------+----------------------+----------------+ | |
4712 | | Attribute | Syntax | REQUIRED? | | |
4713 | +----------------------------+----------------------+----------------+ | |
4714 | | job-media-sheets | integer (0:MAX) | | | |
4715 | +----------------------------+----------------------+----------------+ | |
4716 | | job-k-octets-processed | integer (0:MAX) | | | |
4717 | +----------------------------+----------------------+----------------+ | |
4718 | | job-impressions-completed | integer (0:MAX) | | | |
4719 | +----------------------------+----------------------+----------------+ | |
4720 | | job-media-sheets-completed | integer (0:MAX) | | | |
4721 | +----------------------------+----------------------+----------------+ | |
4722 | | attributes-charset | charset | REQUIRED | | |
4723 | +----------------------------+----------------------+----------------+ | |
4724 | | attributes-natural-language| naturalLanguage | REQUIRED | | |
4725 | +----------------------------+----------------------+----------------+ | |
4726 | ||
4727 | ||
4728 | 4.3.1 job-uri (uri) | |
4729 | ||
4730 | This REQUIRED attribute contains the URI for the job. The Printer | |
4731 | object, on receipt of a new job, generates a URI which identifies the | |
4732 | new Job. The Printer object returns the value of the "job-uri" | |
4733 | attribute as part of the response to a create request. The precise | |
4734 | format of a Job URI is implementation dependent. If the Printer | |
4735 | object supports more than one URI and there is some relationship | |
4736 | between the newly formed Job URI and the Printer object's URI, the | |
4737 | Printer object uses the Printer URI supplied by the client in the | |
4738 | create request. For example, if the create request comes in over a | |
4739 | secure channel, the new Job URI MUST use the same secure channel. | |
4740 | This can be guaranteed because the Printer object is responsible for | |
4741 | generating the Job URI and the Printer object is aware of its | |
4742 | security configuration and policy as well as the Printer URI used in | |
4743 | the create request. | |
4744 | ||
4745 | For a description of this attribute and its relationship to "job-id" | |
4746 | and "job-printer-uri" attribute, see the discussion in section 2.4 on | |
4747 | "Object Identity". | |
4748 | ||
4749 | 4.3.2 job-id (integer(1:MAX)) | |
4750 | ||
4751 | This REQUIRED attribute contains the ID of the job. The Printer, on | |
4752 | receipt of a new job, generates an ID which identifies the new Job on | |
4753 | that Printer. The Printer returns the value of the "job-id" | |
4754 | attribute as part of the response to a create request. The 0 value | |
4755 | is not included to allow for compatibility with SNMP index values | |
4756 | which also cannot be 0. | |
4757 | ||
4758 | ||
4759 | ||
4760 | ||
4761 | ||
4762 | deBry, et al. Experimental [Page 85] | |
4763 | \f | |
4764 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4765 | ||
4766 | ||
4767 | For a description of this attribute and its relationship to "job-uri" | |
4768 | and "job-printer-uri" attribute, see the discussion in section 2.4 on | |
4769 | "Object Identity". | |
4770 | ||
4771 | 4.3.3 job-printer-uri (uri) | |
4772 | ||
4773 | This REQUIRED attribute identifies the Printer object that created | |
4774 | this Job object. When a Printer object creates a Job object, it | |
4775 | populates this attribute with the Printer object URI that was used in | |
4776 | the create request. This attribute permits a client to identify the | |
4777 | Printer object that created this Job object when only the Job | |
4778 | object's URI is available to the client. The client queries the | |
4779 | creating Printer object to determine which languages, charsets, | |
4780 | operations, are supported for this Job. | |
4781 | ||
4782 | For a description of this attribute and its relationship to "job-uri" | |
4783 | and "job-id" attribute, see the discussion in section 2.4 on "Object | |
4784 | Identity". | |
4785 | ||
4786 | 4.3.4 job-more-info (uri) | |
4787 | ||
4788 | Similar to "printer-more-info", this attribute contains the URI | |
4789 | referencing some resource with more information about this Job | |
4790 | object, perhaps an HTML page containing information about the Job. | |
4791 | ||
4792 | 4.3.5 job-name (name(MAX)) | |
4793 | ||
4794 | This REQUIRED attribute is the name of the job. It is a name that is | |
4795 | more user friendly than the "job-uri" attribute value. It does not | |
4796 | need to be unique between Jobs. The Job's "job-name" attribute is | |
4797 | set to the value supplied by the client in the "job-name" operation | |
4798 | attribute in the create request (see Section 3.2.1.1). If, however, | |
4799 | the "job-name" operation attribute is not supplied by the client in | |
4800 | the create request, the Printer object, on creation of the Job, MUST | |
4801 | generate a name. The printer SHOULD generate the value of the Job's | |
4802 | "job-name" attribute from the first of the following sources that | |
4803 | produces a value: 1) the "document-name" operation attribute of the | |
4804 | first (or only) document, 2) the "document-URI" attribute of the | |
4805 | first (or only) document, or 3) any other piece of Job specific | |
4806 | and/or Document Content information. | |
4807 | ||
4808 | 4.3.6 job-originating-user-name (name(MAX)) | |
4809 | ||
4810 | This REQUIRED attribute contains the name of the end user that | |
4811 | submitted the print job. The Printer object sets this attribute to | |
4812 | the most authenticated printable name that it can obtain from the | |
4813 | authentication service over which the IPP operation was received. | |
4814 | ||
4815 | ||
4816 | ||
4817 | ||
4818 | deBry, et al. Experimental [Page 86] | |
4819 | \f | |
4820 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4821 | ||
4822 | ||
4823 | Only if such is not available, does the Printer object use the value | |
4824 | supplied by the client in the "requesting-user-name" operation | |
4825 | attribute of the create operation (see Section 8). | |
4826 | ||
4827 | Note: The Printer object needs to keep an internal originating user | |
4828 | id of some form, typically as a credential of a principal, with the | |
4829 | Job object. Since such an internal attribute is implementation- | |
4830 | dependent and not of interest to clients, it is not specified as a | |
4831 | Job Description attribute. This originating user id is used for | |
4832 | authorization checks (if any) on all subsequent operation. | |
4833 | ||
4834 | 4.3.7 job-state (type1 enum) | |
4835 | ||
4836 | This REQUIRED attribute identifies the current state of the job. | |
4837 | Even though the IPP protocol defines eight values for job states, | |
4838 | implementations only need to support those states which are | |
4839 | appropriate for the particular implementation. In other words, a | |
4840 | Printer supports only those job states implemented by the output | |
4841 | device and available to the Printer object implementation. | |
4842 | ||
4843 | Standard enum values are: | |
4844 | ||
4845 | Values Symbolic Name and Description | |
4846 | ||
4847 | '3' 'pending': The job is a candidate to start processing, but | |
4848 | is not yet processing. | |
4849 | ||
4850 | '4' 'pending-held': The job is not a candidate for processing | |
4851 | for any number of reasons but will return to the ' | |
4852 | pending' state as soon as the reasons are no longer | |
4853 | present. The job's "job-state-reason" attribute MUST | |
4854 | indicate why the job is no longer a candidate for | |
4855 | processing. | |
4856 | ||
4857 | '5' 'processing': One or more of: | |
4858 | ||
4859 | 1. the job is using, or is attempting to use, one or | |
4860 | more purely software processes that are analyzing, | |
4861 | creating, or interpreting a PDL, etc., | |
4862 | 2. the job is using, or is attempting to use, one or | |
4863 | more hardware devices that are interpreting a PDL, | |
4864 | making marks on a medium, and/or performing finishing, | |
4865 | such as stapling, etc., | |
4866 | 3. the Printer object has made the job ready for | |
4867 | printing, but the output device is not yet printing | |
4868 | it, either because the job hasn't reached the output | |
4869 | ||
4870 | ||
4871 | ||
4872 | ||
4873 | ||
4874 | deBry, et al. Experimental [Page 87] | |
4875 | \f | |
4876 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4877 | ||
4878 | ||
4879 | device or because the job is queued in the output | |
4880 | device or some other spooler, awaiting the output | |
4881 | device to print it. | |
4882 | ||
4883 | When the job is in the 'processing' state, the entire | |
4884 | job state includes the detailed status represented in | |
4885 | the printer's "printer-state", "printer-state- | |
4886 | reasons", and "printer-state-message" attributes. | |
4887 | ||
4888 | Implementations MAY, though they NEED NOT, include | |
4889 | additional values in the job's "job-state-reasons" | |
4890 | attribute to indicate the progress of the job, such as | |
4891 | adding the 'job-printing' value to indicate when the | |
4892 | output device is actually making marks on paper and/or | |
4893 | the 'processing-to-stop-point' value to indicate that | |
4894 | the IPP object is in the process of canceling or | |
4895 | aborting the job. Most implementations won't bother | |
4896 | with this nuance. | |
4897 | ||
4898 | '6' 'processing-stopped': The job has stopped while processing | |
4899 | for any number of reasons and will return to the ' | |
4900 | processing' state as soon as the reasons are no longer | |
4901 | present. | |
4902 | ||
4903 | The job's "job-state-reason" attribute MAY indicate | |
4904 | why the job has stopped processing. For example, if | |
4905 | the output device is stopped, the 'printer-stopped' | |
4906 | value MAY be included in the job's "job-state-reasons" | |
4907 | attribute. | |
4908 | ||
4909 | Note: When an output device is stopped, the device | |
4910 | usually indicates its condition in human readable form | |
4911 | locally at the device. A client can obtain more | |
4912 | complete device status remotely by querying the | |
4913 | Printer object's "printer-state", "printer-state- | |
4914 | reasons" and "printer-state-message" attributes. | |
4915 | ||
4916 | '7' 'canceled': The job has been canceled by a Cancel-Job | |
4917 | operation and the Printer object has completed | |
4918 | canceling the job and all job status attributes have | |
4919 | reached their final values for the job. While the | |
4920 | Printer object is canceling the job, the job remains | |
4921 | in its current state, but the job's "job-state- | |
4922 | reasons" attribute SHOULD contain the 'processing-to- | |
4923 | stop-point' value and one of the 'canceled-by-user', ' | |
4924 | canceled-by-operator', or 'canceled-at-device' value. | |
4925 | ||
4926 | ||
4927 | ||
4928 | ||
4929 | ||
4930 | deBry, et al. Experimental [Page 88] | |
4931 | \f | |
4932 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4933 | ||
4934 | ||
4935 | When the job moves to the 'canceled' state, the ' | |
4936 | processing-to-stop-point' value, if present, MUST be | |
4937 | removed, but the 'canceled-by-xxx', if present, MUST | |
4938 | remain. | |
4939 | ||
4940 | '8' 'aborted': The job has been aborted by the system, usually | |
4941 | while the job was in the 'processing' or 'processing- | |
4942 | stopped' state and the Printer has completed aborting | |
4943 | the job and all job status attributes have reached | |
4944 | their final values for the job. While the Printer | |
4945 | object is aborting the job, the job remains in its | |
4946 | current state, but the job's "job-state-reasons" | |
4947 | attribute SHOULD contain the 'processing-to-stop- | |
4948 | point' and 'aborted-by-system' values. When the job | |
4949 | moves to the 'aborted' state, the 'processing-to- | |
4950 | stop-point' value, if present, MUST be removed, but | |
4951 | the 'aborted-by-system' value, if present, MUST | |
4952 | remain. | |
4953 | ||
4954 | '9' 'completed': The job has completed successfully or with | |
4955 | warnings or errors after processing and all of the job | |
4956 | media sheets have been successfully stacked in the | |
4957 | appropriate output bin(s) and all job status | |
4958 | attributes have reached their final values for the | |
4959 | job. The job's "job-state-reasons" attribute SHOULD | |
4960 | contain one of: 'completed-successfully', ' | |
4961 | completed-with-warnings', or 'completed-with-errors' | |
4962 | values. | |
4963 | ||
4964 | The final value for this attribute MUST be one of: 'completed', ' | |
4965 | canceled', or 'aborted' before the Printer removes the job | |
4966 | altogether. The length of time that jobs remain in the 'canceled', ' | |
4967 | aborted', and 'completed' states depends on implementation. | |
4968 | ||
4969 | The following figure shows the normal job state transitions. | |
4970 | ||
4971 | +----> canceled | |
4972 | / | |
4973 | +----> pending --------> processing ---------+------> completed | |
4974 | | ^ ^ \ | |
4975 | --->+ | | +----> aborted | |
4976 | | v v / | |
4977 | +----> pending-held processing-stopped ---+ | |
4978 | ||
4979 | Normally a job progresses from left to right. Other state | |
4980 | transitions are unlikely, but are not forbidden. Not shown are the | |
4981 | transitions to the 'canceled' state from the 'pending', 'pending- | |
4982 | held', and 'processing-stopped' states. | |
4983 | ||
4984 | ||
4985 | ||
4986 | deBry, et al. Experimental [Page 89] | |
4987 | \f | |
4988 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
4989 | ||
4990 | ||
4991 | Jobs reach one of the three terminal states: 'completed', 'canceled', | |
4992 | or 'aborted', after the jobs have completed all activity, including | |
4993 | stacking output media, after the jobs have completed all activity, | |
4994 | and all job status attributes have reached their final values for the | |
4995 | job. | |
4996 | ||
4997 | Note: As with all other IPP attributes, if the implementation can not | |
4998 | determine the correct value for this attribute, it SHOULD respond | |
4999 | with the out-of-band value 'unknown' (see section 4.1) rather than | |
5000 | try to guess at some possibly incorrect value and give the end user | |
5001 | the wrong impression about the state of the Job object. For example, | |
5002 | if the implementation is just a gateway into some printing system | |
5003 | that does not provide detailed status about the print job, the IPP | |
5004 | Job object's state might literally be 'unknown'. | |
5005 | ||
5006 | 4.3.8 job-state-reasons (1setOf type2 keyword) | |
5007 | ||
5008 | This attribute provides additional information about the job's | |
5009 | current state, i.e., information that augments the value of the job's | |
5010 | "job-state" attribute. | |
5011 | ||
5012 | Implementation of these values is OPTIONAL, i.e., a Printer NEED NOT | |
5013 | implement them, even if (1) the output device supports the | |
5014 | functionality represented by the reason and (2) is available to the | |
5015 | Printer object implementation. These values MAY be used with any job | |
5016 | state or states for which the reason makes sense. Furthermore, when | |
5017 | implemented, the Printer MUST return these values when the reason | |
5018 | applies and MUST NOT return them when the reason no longer applies | |
5019 | whether the value of the Job's "job-state" attribute changed or not. | |
5020 | When the Job does not have any reasons for being in its current | |
5021 | state, the value of the Job's "job-state-reasons" attribute MUST be ' | |
5022 | none'. | |
5023 | ||
5024 | Note: While values cannot be added to the 'job-state' attribute | |
5025 | without impacting deployed clients that take actions upon receiving | |
5026 | "job-state" values, it is the intent that additional "job-state- | |
5027 | reasons" values can be defined and registered without impacting such | |
5028 | deployed clients. In other words, the "job-state-reasons" attribute | |
5029 | is intended to be extensible. | |
5030 | ||
5031 | The following standard keyword values are defined. For ease of | |
5032 | understanding, the values are presented in the order in which the | |
5033 | reasons are likely to occur (if implemented), starting with the ' | |
5034 | job-incoming' value: | |
5035 | ||
5036 | 'none': There are no reasons for the job's current state. | |
5037 | 'job-incoming': The Create-Job operation has been accepted by the | |
5038 | Printer, but the Printer is expecting additional Send-Document | |
5039 | ||
5040 | ||
5041 | ||
5042 | deBry, et al. Experimental [Page 90] | |
5043 | \f | |
5044 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5045 | ||
5046 | ||
5047 | and/or Send-URI operations and/or is accessing/accepting | |
5048 | document data. | |
5049 | 'submission-interrupted': The job was not completely submitted for | |
5050 | some unforeseen reason, such as: (1) the Printer has crashed | |
5051 | before the job was closed by the client, (2) the Printer or the | |
5052 | document transfer method has crashed in some non-recoverable way | |
5053 | before the document data was entirely transferred to the | |
5054 | Printer, (3) the client crashed or failed to close the job | |
5055 | before the time-out period. See section 4.4.28. | |
5056 | 'job-outgoing': The Printer is transmitting the job to the output | |
5057 | device. | |
5058 | 'job-hold-until-specified': The value of the job's "job-hold- | |
5059 | until" attribute was specified with a time period that is still | |
5060 | in the future. The job MUST NOT be a candidate for processing | |
5061 | until this reason is removed and there are no other reasons to | |
5062 | hold the job. | |
5063 | 'resources-are-not-ready': At least one of the resources needed by | |
5064 | the job, such as media, fonts, resource objects, etc., is not | |
5065 | ready on any of the physical printer's for which the job is a | |
5066 | candidate. This condition MAY be detected when the job is | |
5067 | accepted, or subsequently while the job is pending or | |
5068 | processing, depending on implementation. The job may remain in | |
5069 | its current state or be moved to the 'pending-held' state, | |
5070 | depending on implementation and/or job scheduling policy. | |
5071 | 'printer-stopped-partly': The value of the Printer's "printer- | |
5072 | state-reasons" attribute contains the value 'stopped-partly'. | |
5073 | 'printer-stopped': The value of the Printer's "printer-state" | |
5074 | attribute is 'stopped'. | |
5075 | 'job-interpreting': Job is in the 'processing' state, but more | |
5076 | specifically, the Printer is interpreting the document data. | |
5077 | 'job-queued': Job is in the 'processing' state, but more | |
5078 | specifically, the Printer has queued the document data. | |
5079 | 'job-transforming': Job is in the 'processing' state, but more | |
5080 | specifically, the Printer is interpreting document data and | |
5081 | producing another electronic representation. | |
5082 | 'job-printing': The output device is marking media. This value is | |
5083 | useful for Printers which spend a great deal of time processing | |
5084 | (1) when no marking is happening and then want to show that | |
5085 | marking is now happening or (2) when the job is in the process | |
5086 | of being canceled or aborted while the job remains in the ' | |
5087 | processing' state, but the marking has not yet stopped so that | |
5088 | impression or sheet counts are still increasing for the job. | |
5089 | 'job-canceled-by-user': The job was canceled by the owner of the | |
5090 | job using the Cancel-Job request, i.e., by a user whose | |
5091 | authenticated identity is the same as the value of the | |
5092 | originating user that created the Job object, or by some other | |
5093 | authorized end-user, such as a member of the job owner's | |
5094 | security group. | |
5095 | ||
5096 | ||
5097 | ||
5098 | deBry, et al. Experimental [Page 91] | |
5099 | \f | |
5100 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5101 | ||
5102 | ||
5103 | 'job-canceled-by-operator': The job was canceled by the operator | |
5104 | using the Cancel-Job request, i.e., by a user who has been | |
5105 | authenticated as having operator privileges (whether local or | |
5106 | remote). If the security policy is to allow anyone to cancel | |
5107 | anyone's job, then this value may be used when the job is | |
5108 | canceled by other than the owner of the job. For such a | |
5109 | security policy, in effect, everyone is an operator as far as | |
5110 | canceling jobs with IPP is concerned. | |
5111 | 'job-canceled-at-device': The job was canceled by an unidentified | |
5112 | local user, i.e., a user at a console at the device. | |
5113 | 'aborted-by-system': The job (1) is in the process of being | |
5114 | aborted, (2) has been aborted by the system and placed in the ' | |
5115 | aborted' state, or (3) has been aborted by the system and placed | |
5116 | in the 'pending-held' state, so that a user or operator can | |
5117 | manually try the job again. | |
5118 | 'processing-to-stop-point': The requester has issued a Cancel-Job | |
5119 | operation or the Printer object has aborted the job, but is | |
5120 | still performing some actions on the job until a specified stop | |
5121 | point occurs or job termination/cleanup is completed. | |
5122 | ||
5123 | This reason is recommended to be used in conjunction with the ' | |
5124 | processing' job state to indicate that the Printer object is | |
5125 | still performing some actions on the job while the job remains | |
5126 | in the 'processing' state. After all the job's job description | |
5127 | attributes have stopped incrementing, the Printer object moves | |
5128 | the job from the 'processing' state to the 'canceled' or ' | |
5129 | aborted' job states. | |
5130 | ||
5131 | 'service-off-line': The Printer is off-line and accepting no jobs. | |
5132 | All 'pending' jobs are put into the 'pending-held' state. This | |
5133 | situation could be true if the service's or document transform's | |
5134 | input is impaired or broken. | |
5135 | 'job-completed-successfully': The job completed successfully. | |
5136 | 'job-completed-with-warnings': The job completed with warnings. | |
5137 | 'job-completed-with-errors': The job completed with errors (and | |
5138 | possibly warnings too). | |
5139 | ||
5140 | 4.3.9 job-state-message (text(MAX)) | |
5141 | ||
5142 | This attribute specifies information about the "job-state" and "job- | |
5143 | state-reasons" attributes in human readable text. If the Printer | |
5144 | object supports this attribute, the Printer object MUST be able to | |
5145 | generate this message in any of the natural languages identified by | |
5146 | the Printer's "generated-natural-language-supported" attribute (see | |
5147 | the "attributes-natural-language" operation attribute specified in | |
5148 | Section 3.1.4.1). | |
5149 | ||
5150 | ||
5151 | ||
5152 | ||
5153 | ||
5154 | deBry, et al. Experimental [Page 92] | |
5155 | \f | |
5156 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5157 | ||
5158 | ||
5159 | Note: the value SHOULD NOT contain additional information not | |
5160 | contained in the values of the "job-state" and "job-states-reasons" | |
5161 | attributes, such as interpreter error information. Otherwise, | |
5162 | application programs might attempt to parse the (localized text). | |
5163 | For such additional information such as interpreter errors for | |
5164 | application program consumption, a new attribute with keyword values, | |
5165 | needs to be developed and registered. | |
5166 | ||
5167 | 4.3.10 number-of-documents (integer(0:MAX)) | |
5168 | ||
5169 | This attribute indicates the number of documents in the job, i.e., | |
5170 | the number of Send-Document, Send-URI, Print-Job, or Print-URI | |
5171 | operations that the Printer has accepted for this job, regardless of | |
5172 | whether the document data has reached the Printer object or not. | |
5173 | ||
5174 | Implementations supporting the OPTIONAL Create-Job/Send- | |
5175 | Document/Send-URI operations SHOULD support this attribute so that | |
5176 | clients can query the number of documents in each job. | |
5177 | ||
5178 | 4.3.11 output-device-assigned (name(127)) | |
5179 | ||
5180 | This attribute identifies the output device to which the Printer | |
5181 | object has assigned this job. If an output device implements an | |
5182 | embedded Printer object, the Printer object NEED NOT set this | |
5183 | attribute. If a print server implements a Printer object, the value | |
5184 | MAY be empty (zero-length string) or not returned until the Printer | |
5185 | object assigns an output device to the job. This attribute is | |
5186 | particularly useful when a single Printer object support multiple | |
5187 | devices (so called "fan-out"). | |
5188 | ||
5189 | 4.3.12 time-at-creation (integer(0:MAX)) | |
5190 | ||
5191 | This attribute indicates the point in time at which the Job object | |
5192 | was created. In order to populate this attribute, the Printer object | |
5193 | uses the value in its "printer-up-time" attribute at the time the Job | |
5194 | object is created. | |
5195 | ||
5196 | 4.3.13 time-at-processing (integer(0:MAX)) | |
5197 | ||
5198 | This attribute indicates the point in time at which the Job object | |
5199 | began processing. In order to populate this attribute, the Printer | |
5200 | object uses the value in its "printer-up-time" attribute at the time | |
5201 | the Job object is moved into the 'processing' state for the first | |
5202 | time. | |
5203 | ||
5204 | ||
5205 | ||
5206 | ||
5207 | ||
5208 | ||
5209 | ||
5210 | deBry, et al. Experimental [Page 93] | |
5211 | \f | |
5212 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5213 | ||
5214 | ||
5215 | 4.3.14 time-at-completed (integer(0:MAX)) | |
5216 | ||
5217 | This attribute indicates the point in time at which the Job object | |
5218 | completed (or was cancelled or aborted). In order to populate this | |
5219 | attribute, the Printer object uses the value in its "printer-up-time" | |
5220 | attribute at the time the Job object is moved into the 'completed' or | |
5221 | 'canceled' or 'aborted' state. | |
5222 | ||
5223 | 4.3.15 number-of-intervening-jobs (integer(0:MAX)) | |
5224 | ||
5225 | This attribute indicates the number of jobs that are "ahead" of this | |
5226 | job in the relative chronological order of expected time to complete | |
5227 | (i.e., the current scheduled order). For efficiency, it is only | |
5228 | necessary to calculate this value when an operation is performed that | |
5229 | requests this attribute. | |
5230 | ||
5231 | 4.3.16 job-message-from-operator (text(127)) | |
5232 | ||
5233 | This attribute provides a message from an operator, system | |
5234 | administrator or "intelligent" process to indicate to the end user | |
5235 | the reasons for modification or other management action taken on a | |
5236 | job. | |
5237 | ||
5238 | 4.3.17 job-k-octets (integer(0:MAX)) | |
5239 | ||
5240 | This attribute specifies the total size of the document(s) in K | |
5241 | octets, i.e., in units of 1024 octets requested to be processed in | |
5242 | the job. The value MUST be rounded up, so that a job between 1 and | |
5243 | 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, | |
5244 | etc. | |
5245 | ||
5246 | This value MUST NOT include the multiplicative factors contributed by | |
5247 | the number of copies specified by the "copies" attribute, independent | |
5248 | of whether the device can process multiple copies without making | |
5249 | multiple passes over the job or document data and independent of | |
5250 | whether the output is collated or not. Thus the value is independent | |
5251 | of the implementation and indicates the size of the document(s) | |
5252 | measured in K octets independent of the number of copies. | |
5253 | ||
5254 | This value MUST also not include the multiplicative factor due to a | |
5255 | copies instruction embedded in the document data. If the document | |
5256 | data actually includes replications of the document data, this value | |
5257 | will include such replication. In other words, this value is always | |
5258 | the size of the source document data, rather than a measure of the | |
5259 | hardcopy output to be produced. | |
5260 | ||
5261 | ||
5262 | ||
5263 | ||
5264 | ||
5265 | ||
5266 | deBry, et al. Experimental [Page 94] | |
5267 | \f | |
5268 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5269 | ||
5270 | ||
5271 | Note: This attribute and the following two attributes ("job- | |
5272 | impressions" and "job-media-sheets") are not intended to be counters; | |
5273 | they are intended to be useful routing and scheduling information if | |
5274 | known. For these three attributes, the Printer object may try to | |
5275 | compute the value if it is not supplied in the create request. Even | |
5276 | if the client does supply a value for these three attributes in the | |
5277 | create request, the Printer object MAY choose to change the value if | |
5278 | the Printer object is able to compute a value which is more accurate | |
5279 | than the client supplied value. The Printer object may be able to | |
5280 | determine the correct value for these three attributes either right | |
5281 | at job submission time or at any later point in time. | |
5282 | ||
5283 | 4.3.18 job-impressions (integer(0:MAX)) | |
5284 | ||
5285 | This attribute specifies the total size in number of impressions of | |
5286 | the document(s) being submitted (see the definition of impression in | |
5287 | section 13.2.5). | |
5288 | ||
5289 | As with "job-k-octets", this value MUST NOT include the | |
5290 | multiplicative factors contributed by the number of copies specified | |
5291 | by the "copies" attribute, independent of whether the device can | |
5292 | process multiple copies without making multiple passes over the job | |
5293 | or document data and independent of whether the output is collated or | |
5294 | not. Thus the value is independent of the implementation and | |
5295 | reflects the size of the document(s) measured in impressions | |
5296 | independent of the number of copies. | |
5297 | ||
5298 | As with "job-k-octets", this value MUST also not include the | |
5299 | multiplicative factor due to a copies instruction embedded in the | |
5300 | document data. If the document data actually includes replications | |
5301 | of the document data, this value will include such replication. In | |
5302 | other words, this value is always the number of impressions in the | |
5303 | source document data, rather than a measure of the number of | |
5304 | impressions to be produced by the job. | |
5305 | ||
5306 | See the Note in the "job-k-octets" attribute that also applies to | |
5307 | this attribute. | |
5308 | ||
5309 | 4.3.19 job-media-sheets (integer(0:MAX)) | |
5310 | ||
5311 | This attribute specifies the total number of media sheets to be | |
5312 | produced for this job. | |
5313 | ||
5314 | Unlike the "job-k-octets" and the "job-impressions" attributes, this | |
5315 | value MUST include the multiplicative factors contributed by the | |
5316 | number of copies specified by the "copies" attribute and a 'number of | |
5317 | copies' instruction embedded in the document data, if any. This | |
5318 | difference allows the system administrator to control the lower and | |
5319 | ||
5320 | ||
5321 | ||
5322 | deBry, et al. Experimental [Page 95] | |
5323 | \f | |
5324 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5325 | ||
5326 | ||
5327 | upper bounds of both (1) the size of the document(s) with "job-k- | |
5328 | octets-supported" and "job-impressions-supported" and (2) the size of | |
5329 | the job with "job-media-sheets-supported". | |
5330 | ||
5331 | See the Note in the "job-k-octets" attribute that also applies to | |
5332 | this attribute. | |
5333 | ||
5334 | 4.3.20 job-k-octets-processed (integer(0:MAX)) | |
5335 | ||
5336 | This attribute specifies the total number of octets processed in K | |
5337 | octets, i.e., in units of 1024 octets so far. The value MUST be | |
5338 | rounded up, so that a job between 1 and 1024 octets inclusive MUST be | |
5339 | indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc. | |
5340 | ||
5341 | For implementations where multiple copies are produced by the | |
5342 | interpreter with only a single pass over the data, the final value | |
5343 | MUST be equal to the value of the "job-k-octets" attribute. For | |
5344 | implementations where multiple copies are produced by the interpreter | |
5345 | by processing the data for each copy, the final value MUST be a | |
5346 | multiple of the value of the "job-k-octets" attribute. | |
5347 | ||
5348 | Note: This attribute and the following two attributes ("job- | |
5349 | impressions-completed" and "job-sheets-completed") are intended to be | |
5350 | counters. That is, the value for a job that has not started | |
5351 | processing MUST be 0. When the job's "job-state" is 'processing' or | |
5352 | 'processing-stopped', this value is intended to contain the amount of | |
5353 | the job that has been processed to the time at which the attributes | |
5354 | are requested. | |
5355 | ||
5356 | 4.3.21 job-impressions-completed (integer(0:MAX)) | |
5357 | ||
5358 | This job attribute specifies the number of impressions completed for | |
5359 | the job so far. For printing devices, the impressions completed | |
5360 | includes interpreting, marking, and stacking the output. | |
5361 | ||
5362 | See the note in "job-k-octets-processed" which also applies to this | |
5363 | attribute. | |
5364 | ||
5365 | 4.3.22 job-media-sheets-completed (integer(0:MAX)) | |
5366 | ||
5367 | This job attribute specifies the media-sheets completed marking and | |
5368 | stacking for the entire job so far whether those sheets have been | |
5369 | processed on one side or on both. | |
5370 | ||
5371 | See the note in "job-k-octets-processed" which also applies to this | |
5372 | attribute. | |
5373 | ||
5374 | ||
5375 | ||
5376 | ||
5377 | ||
5378 | deBry, et al. Experimental [Page 96] | |
5379 | \f | |
5380 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5381 | ||
5382 | ||
5383 | 4.3.23 attributes-charset (charset) | |
5384 | ||
5385 | This REQUIRED attribute is populated using the value in the client | |
5386 | supplied "attributes-charset" attribute in the create request. It | |
5387 | identifies the charset (coded character set and encoding method) used | |
5388 | by any Job attributes with attribute syntax 'text' and 'name' that | |
5389 | were supplied by the client in the create request. See Section 3.1.4 | |
5390 | for a complete description of the "attributes-charset" operation | |
5391 | attribute. | |
5392 | ||
5393 | This attribute does not indicate the charset in which the 'text' and | |
5394 | 'name' values are stored internally in the Job object. The internal | |
5395 | charset is implementation-defined. The IPP object MUST convert from | |
5396 | whatever the internal charset is to that being requested in an | |
5397 | operation as specified in Section 3.1.4. | |
5398 | ||
5399 | 4.3.24 attributes-natural-language (naturalLanguage) | |
5400 | ||
5401 | This REQUIRED attribute is populated using the value in the client | |
5402 | supplied "attributes-natural-language" attribute in the create | |
5403 | request. It identifies the natural language used for any Job | |
5404 | attributes with attribute syntax 'text' and 'name' that were supplied | |
5405 | by the client in the create request. See Section 3.1.4 for a | |
5406 | complete description of the "attributes-natural-language" operation | |
5407 | attribute. See Sections 4.1.1.2 and 4.1.2.2 for how a Natural | |
5408 | Language Override may be supplied explicitly for each 'text' and ' | |
5409 | name' attribute value that differs from the value identified by the | |
5410 | "attributes-natural-language" attribute. | |
5411 | ||
5412 | 4.4 Printer Description Attributes | |
5413 | ||
5414 | These attributes form the attribute group called "printer- | |
5415 | description". The following table summarizes these attributes, their | |
5416 | syntax, and whether or not they are REQUIRED for a Printer object to | |
5417 | support. If they are not indicated as REQUIRED, they are OPTIONAL. | |
5418 | The maximum size in octets for 'text' and 'name' attributes is | |
5419 | indicated in parenthesizes. | |
5420 | ||
5421 | Note: How these attributes are set by an Administrator is outside the | |
5422 | scope of this specification. | |
5423 | ||
5424 | ||
5425 | ||
5426 | ||
5427 | ||
5428 | ||
5429 | ||
5430 | ||
5431 | ||
5432 | ||
5433 | ||
5434 | deBry, et al. Experimental [Page 97] | |
5435 | \f | |
5436 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5437 | ||
5438 | ||
5439 | +----------------------------+----------------------+----------------+ | |
5440 | | Attribute | Syntax | REQUIRED? | | |
5441 | +----------------------------+----------------------+----------------+ | |
5442 | | printer-uri-supported | 1setOf uri | REQUIRED | | |
5443 | +----------------------------+----------------------+----------------+ | |
5444 | | uri-security-supported | 1setOf type2 keyword | REQUIRED | | |
5445 | +----------------------------+----------------------+----------------+ | |
5446 | | printer-name | name (127) | REQUIRED | | |
5447 | +----------------------------+----------------------+----------------+ | |
5448 | | printer-location | text (127) | | | |
5449 | +----------------------------+----------------------+----------------+ | |
5450 | | printer-info | text (127) | | | |
5451 | +----------------------------+----------------------+----------------+ | |
5452 | | printer-more-info | uri | | | |
5453 | +----------------------------+----------------------+----------------+ | |
5454 | | printer-driver-installer | uri | | | |
5455 | +----------------------------+----------------------+----------------+ | |
5456 | | printer-make-and-model | text (127) | | | |
5457 | +----------------------------+----------------------+----------------+ | |
5458 | | printer-more-info- | uri | | | |
5459 | | manufacturer | | | | |
5460 | +----------------------------+----------------------+----------------+ | |
5461 | | printer-state | type1 enum | REQUIRED | | |
5462 | +----------------------------+----------------------+----------------+ | |
5463 | | printer-state-reasons | 1setOf type2 keyword | | | |
5464 | +----------------------------+----------------------+----------------+ | |
5465 | | printer-state-message | text (MAX) | | | |
5466 | +----------------------------+----------------------+----------------+ | |
5467 | | operations-supported | 1setOf type2 enum | REQUIRED | | |
5468 | +----------------------------+----------------------+----------------+ | |
5469 | | charset-configured | charset | REQUIRED | | |
5470 | +----------------------------+----------------------+----------------+ | |
5471 | | charset-supported | 1setOf charset | REQUIRED | | |
5472 | +----------------------------+----------------------+----------------+ | |
5473 | | natural-language-configured| naturalLanguage | REQUIRED | | |
5474 | +----------------------------+----------------------+----------------+ | |
5475 | | generated-natural-language-| 1setOf | REQUIRED | | |
5476 | | supported | naturalLanguage | | | |
5477 | +----------------------------+----------------------+----------------+ | |
5478 | | document-format-default | mimeMediaType | REQUIRED | | |
5479 | +----------------------------+----------------------+----------------+ | |
5480 | | document-format- | 1setOf | REQUIRED | | |
5481 | | supported | mimeMediaType | | | |
5482 | +----------------------------+----------------------+----------------+ | |
5483 | | printer-is-accepting-jobs | boolean | REQUIRED | | |
5484 | +----------------------------+----------------------+----------------+ | |
5485 | | queued-job-count | integer (0:MAX) | RECOMMENDED | | |
5486 | +----------------------------+----------------------+----------------+ | |
5487 | ||
5488 | ||
5489 | ||
5490 | deBry, et al. Experimental [Page 98] | |
5491 | \f | |
5492 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5493 | ||
5494 | ||
5495 | +----------------------------+----------------------+----------------+ | |
5496 | | Attribute | Syntax | REQUIRED? | | |
5497 | +----------------------------+----------------------+----------------+ | |
5498 | | printer-message-from- | text (127) | | | |
5499 | | operator | | | | |
5500 | +----------------------------+----------------------+----------------+ | |
5501 | | color-supported | boolean | | | |
5502 | +----------------------------+----------------------+----------------+ | |
5503 | | reference-uri-schemes- | 1setOf uriScheme | | | |
5504 | | supported | | | | |
5505 | +----------------------------+----------------------+----------------+ | |
5506 | | pdl-override-supported | type2 keyword | REQUIRED | | |
5507 | +----------------------------+----------------------+----------------+ | |
5508 | | printer-up-time | integer (1:MAX) | REQUIRED | | |
5509 | +----------------------------+----------------------+----------------+ | |
5510 | | printer-current-time | dateTime | | | |
5511 | +----------------------------+----------------------+----------------+ | |
5512 | | multiple-operation-time-out| integer (1:MAX) | | | |
5513 | +----------------------------+----------------------+----------------+ | |
5514 | | compression-supported | 1setOf type3 keyword | | | |
5515 | +----------------------------+----------------------+----------------+ | |
5516 | | job-k-octets-supported | rangeOfInteger | | | |
5517 | | | (0:MAX) | | | |
5518 | +----------------------------+----------------------+----------------+ | |
5519 | | job-impressions-supported | rangeOfInteger | | | |
5520 | | | (0:MAX) | | | |
5521 | +----------------------------+----------------------+----------------+ | |
5522 | | job-media-sheets-supported | rangeOfInteger | | | |
5523 | | | (0:MAX) | | | |
5524 | +----------------------------+----------------------+----------------+ | |
5525 | ||
5526 | 4.4.1 printer-uri-supported (1setOf uri) | |
5527 | ||
5528 | This REQUIRED Printer attribute contains at least one URI for the | |
5529 | Printer object. It OPTIONALLY contains more than one URI for the | |
5530 | Printer object. An administrator determines a Printer object's | |
5531 | URI(s) and configures this attribute to contain those URIs by some | |
5532 | means outside the scope of IPP/1.0. The precise format of this URI | |
5533 | is implementation dependent and depends on the protocol. See the | |
5534 | next section for a description "uri-security-supported" which is the | |
5535 | REQUIRED companion attribute to this "printer-uri-supported" | |
5536 | attribute. See section 2.4 on Printer object identity and section | |
5537 | 8.2 on security and URIs for more information. | |
5538 | ||
5539 | ||
5540 | ||
5541 | ||
5542 | ||
5543 | ||
5544 | ||
5545 | ||
5546 | deBry, et al. Experimental [Page 99] | |
5547 | \f | |
5548 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5549 | ||
5550 | ||
5551 | 4.4.2 uri-security-supported (1setOf type2 keyword) | |
5552 | ||
5553 | This REQUIRED Printer attribute MUST have the same cardinality | |
5554 | (contain the same number of values) as the "printer-uri-supported" | |
5555 | attribute. This attribute identifies the security mechanisms used | |
5556 | for each URI listed in the "printer-uri-supported" attribute. The "i | |
5557 | th" value in "uri-security-supported" corresponds to the "i th" value | |
5558 | in "printer-uri-supported" and it describes the security mechanisms | |
5559 | used for accessing the Printer object via that URI. The following | |
5560 | standard values are defined: | |
5561 | ||
5562 | 'none': There are no secure communication channel protocols in use | |
5563 | for the given URI. | |
5564 | ||
5565 | 'ssl3': SSL3 [SSL] is the secure communications channel protocol in | |
5566 | use for the given URI. | |
5567 | ||
5568 | Consider the following example. For a single Printer object, an | |
5569 | administrator configures the "printer-uri-supported" and "uri- | |
5570 | security-supported" attributes as follows: | |
5571 | ||
5572 | "printer-uri-supported": 'http://acme.com/open-use-printer', ' | |
5573 | http://acme.com/restricted-use-printer', ' | |
5574 | http://acme.com/private-printer' | |
5575 | "uri-security-supported": 'none', 'none', 'ssl3' | |
5576 | ||
5577 | In this case, one Printer object has three URIs. | |
5578 | ||
5579 | - For the first URI, 'http://acme.com/open-use-printer', the value | |
5580 | 'none' in "uri-security-supported" indicates that there is no | |
5581 | secure channel protocol configured to run under HTTP. The name | |
5582 | implies that there is no Basic or Digest authentication being | |
5583 | used, but it is up to the client to determine that while using | |
5584 | HTTP underneath the IPP application protocol. | |
5585 | - For the second URI, 'http://acme.com/restricted-use-printer', the | |
5586 | value 'none' in "uri-security-supported" indicates that there is | |
5587 | no secure channel protocol configured to run under HTTP. In | |
5588 | this case, although the name does imply that there is some sort | |
5589 | of Basic or Digest authentication being used within HTTP, it is | |
5590 | up to the client to determine that while using HTTP and by | |
5591 | processing any '401 Unauthorized' HTTP error messages. | |
5592 | - For the third URI, 'http://acme.com/private-printer', the value ' | |
5593 | ssl3' in "uri-security-supported" indicates that SSL3 is being | |
5594 | used to secure the channel. The client SHOULD be prepared to | |
5595 | use SSL3 framing to negotiate an acceptable ciphersuite to use | |
5596 | while communicating with the Printer object. In this case, the | |
5597 | name implies the use of a secure communications channel, but the | |
5598 | fact is made explicit by the presence of the 'ssl3' value in | |
5599 | ||
5600 | ||
5601 | ||
5602 | deBry, et al. Experimental [Page 100] | |
5603 | \f | |
5604 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5605 | ||
5606 | ||
5607 | "uri-security-supported". The client does not need to resort to | |
5608 | understanding which security it must use by following naming | |
5609 | conventions or by parsing the URI to determine which security | |
5610 | mechanisms are implied. | |
5611 | ||
5612 | It is expected that many IPP Printer objects will be configured to | |
5613 | support only one channel (either configured to use SSL3 access or | |
5614 | not), and will therefore only ever have one URI listed in the | |
5615 | "printer-uri-supported" attribute. No matter the configuration of | |
5616 | the Printer object (whether it has only one URI or more than one | |
5617 | URI), a client MUST supply only one URI in the target "printer-uri" | |
5618 | operation attribute. | |
5619 | ||
5620 | 4.4.3 printer-name (name(127)) | |
5621 | ||
5622 | This REQUIRED Printer attribute contains the name of the Printer | |
5623 | object. It is a name that is more end-user friendly than a URI. An | |
5624 | administrator determines a printer's name and sets this attribute to | |
5625 | that name. This name may be the last part of the printer's URI or it | |
5626 | may be unrelated. In non-US-English locales, a name may contain | |
5627 | characters that are not allowed in a URI. | |
5628 | ||
5629 | 4.4.4 printer-location (text(127)) | |
5630 | ||
5631 | This Printer attribute identifies the location of the device. This | |
5632 | could include things like: "in Room 123A, second floor of building | |
5633 | XYZ". | |
5634 | ||
5635 | 4.4.5 printer-info (text(127)) | |
5636 | ||
5637 | This Printer attribute identifies the descriptive information about | |
5638 | this Printer object. This could include things like: "This printer | |
5639 | can be used for printing color transparencies for HR presentations", | |
5640 | or "Out of courtesy for others, please print only small (1-5 page) | |
5641 | jobs at this printer", or even "This printer is going away on July 1, | |
5642 | 1997, please find a new printer". | |
5643 | ||
5644 | 4.4.6 printer-more-info (uri) | |
5645 | ||
5646 | This Printer attribute contains a URI used to obtain more information | |
5647 | about this specific Printer object. For example, this could be an | |
5648 | HTTP type URI referencing an HTML page accessible to a Web Browser. | |
5649 | The information obtained from this URI is intended for end user | |
5650 | consumption. Features outside the scope of IPP can be accessed from | |
5651 | this URI. The information is intended to be specific to this printer | |
5652 | instance and site specific services (e.g. job pricing, services | |
5653 | offered, end user assistance). The device manufacturer may initially | |
5654 | populate this attribute. | |
5655 | ||
5656 | ||
5657 | ||
5658 | deBry, et al. Experimental [Page 101] | |
5659 | \f | |
5660 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5661 | ||
5662 | ||
5663 | 4.4.7 printer-driver-installer (uri) | |
5664 | ||
5665 | This Printer attribute contains a URI to use to locate the driver | |
5666 | installer for this Printer object. This attribute is intended for | |
5667 | consumption by automata. The mechanics of print driver installation | |
5668 | is outside the scope of IPP. The device manufacturer may initially | |
5669 | populate this attribute. | |
5670 | ||
5671 | 4.4.8 printer-make-and-model (text(127)) | |
5672 | ||
5673 | This Printer attribute identifies the make and model of the device. | |
5674 | The device manufacturer may initially populate this attribute. | |
5675 | ||
5676 | 4.4.9 printer-more-info-manufacturer (uri) | |
5677 | ||
5678 | This Printer attribute contains a URI used to obtain more information | |
5679 | about this type of device. The information obtained from this URI is | |
5680 | intended for end user consumption. Features outside the scope of IPP | |
5681 | can be accessed from this URI (e.g., latest firmware, upgrades, print | |
5682 | drivers, optional features available, details on color support). The | |
5683 | information is intended to be germane to this printer without regard | |
5684 | to site specific modifications or services. The device manufacturer | |
5685 | may initially populate this attribute. | |
5686 | ||
5687 | 4.4.10 printer-state (type1 enum) | |
5688 | ||
5689 | This REQUIRED Printer attribute identifies the current state of the | |
5690 | device. The "printer-state reasons" attribute augments the | |
5691 | "printer-state" attribute to give more detailed information about the | |
5692 | Printer in the given printer state. | |
5693 | ||
5694 | A Printer object need only update this attribute before responding to | |
5695 | an operation which requests the attribute; the Printer object NEED | |
5696 | NOT update this attribute continually, since asynchronous event | |
5697 | notification is not part of IPP/1.0. A Printer NEED NOT implement | |
5698 | all values if they are not applicable to a given implementation. | |
5699 | ||
5700 | The following standard enum values are defined: | |
5701 | ||
5702 | Value Symbolic Name and Description | |
5703 | ||
5704 | '3' 'idle': If a Printer receives a job (whose required | |
5705 | resources are ready) while in this state, such a job | |
5706 | MUST transit into the 'processing' state immediately. | |
5707 | If the "printer-state-reasons" attribute contains any | |
5708 | reasons, they MUST be reasons that would not prevent a | |
5709 | job from transiting into the 'processing' state | |
5710 | immediately, e.g., 'toner-low'. Note: if a Printer | |
5711 | ||
5712 | ||
5713 | ||
5714 | deBry, et al. Experimental [Page 102] | |
5715 | \f | |
5716 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5717 | ||
5718 | ||
5719 | controls more than one output device, the above | |
5720 | definition implies that a Printer is 'idle' if at | |
5721 | least one output device is idle. | |
5722 | ||
5723 | '4' 'processing': If a Printer receives a job (whose required | |
5724 | resources are ready) while in this state, such a job | |
5725 | MUST transit into the 'pending' state immediately. | |
5726 | Such a job MUST transit into the 'processing' state | |
5727 | only after jobs ahead of it complete. If the | |
5728 | "printer-state-reasons" attribute contains any | |
5729 | reasons, they MUST be reasons that do not prevent the | |
5730 | current job from printing, e.g. 'toner-low'. Note: | |
5731 | if a Printer controls more than one output device, the | |
5732 | above definition implies that a Printer is ' | |
5733 | processing' if at least one output device is | |
5734 | processing, and none is idle. | |
5735 | ||
5736 | '5' 'stopped': If a Printer receives a job (whose required | |
5737 | resources are ready) while in this state, such a job | |
5738 | MUST transit into the 'pending' state immediately. | |
5739 | Such a job MUST transit into the 'processing' state | |
5740 | only after some human fixes the problem that stopped | |
5741 | the printer and after jobs ahead of it complete | |
5742 | processing. If supported, the "printer-state-reasons" | |
5743 | attribute MUST contain at least one reason, e.g. ' | |
5744 | media-jam', which prevents it from either processing | |
5745 | the current job or transitioning a 'pending' job to | |
5746 | the 'processing' state. | |
5747 | ||
5748 | Note: if a Printer controls more than one output | |
5749 | device, the above definition implies that a Printer is | |
5750 | 'stopped' only if all output devices are stopped. | |
5751 | Also, it is tempting to define 'stopped' as when a | |
5752 | sufficient number of output devices are stopped and | |
5753 | leave it to an implementation to define the sufficient | |
5754 | number. But such a rule complicates the definition of | |
5755 | 'stopped' and 'processing'. For example, with this | |
5756 | alternate definition of 'stopped', a job can move from | |
5757 | 'pending' to 'processing' without human intervention, | |
5758 | even though the Printer is stopped. | |
5759 | ||
5760 | 4.4.11 printer-state-reasons (1setOf type2 keyword) | |
5761 | ||
5762 | This Printer attribute supplies additional detail about the device's | |
5763 | state. | |
5764 | ||
5765 | ||
5766 | ||
5767 | ||
5768 | ||
5769 | ||
5770 | deBry, et al. Experimental [Page 103] | |
5771 | \f | |
5772 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5773 | ||
5774 | ||
5775 | Each keyword value MAY have a suffix to indicate its level of | |
5776 | severity. The three levels are: report (least severe), warning, and | |
5777 | error (most severe). | |
5778 | ||
5779 | - '-report': This suffix indicates that the reason is a "report". | |
5780 | An implementation may choose to omit some or all reports. Some | |
5781 | reports specify finer granularity about the printer state; | |
5782 | others serve as a precursor to a warning. A report MUST contain | |
5783 | nothing that could affect the printed output. | |
5784 | - '-warning': This suffix indicates that the reason is a "warning". | |
5785 | An implementation may choose to omit some or all warnings. | |
5786 | Warnings serve as a precursor to an error. A warning MUST | |
5787 | contain nothing that prevents a job from completing, though in | |
5788 | some cases the output may be of lower quality. | |
5789 | - '-error': This suffix indicates that the reason is an "error". | |
5790 | An implementation MUST include all errors. If this attribute | |
5791 | contains one or more errors, printer MUST be in the stopped | |
5792 | state. | |
5793 | ||
5794 | If the implementation does not add any one of the three suffixes, all | |
5795 | parties MUST assume that the reason is an "error". | |
5796 | ||
5797 | If a Printer object controls more than one output device, each value | |
5798 | of this attribute MAY apply to one or more of the output devices. An | |
5799 | error on one output device that does not stop the Printer object as a | |
5800 | whole MAY appear as a warning in the Printer's "printer-state-reasons | |
5801 | attribute". If the "printer-state" for such a Printer has a value of | |
5802 | 'stopped', then there MUST be an error reason among the values in the | |
5803 | "printer-state-reasons" attribute. | |
5804 | ||
5805 | The following standard keyword values are defined: | |
5806 | ||
5807 | 'other': The device has detected an error other than one listed in | |
5808 | this document. | |
5809 | 'none': There are not reasons. This state reason is semantically | |
5810 | equivalent to "printer-state-reasons" without any value. | |
5811 | 'media-needed': A tray has run out of media. | |
5812 | 'media-jam': The device has a media jam. | |
5813 | 'paused': Someone has paused the Printer object. In this state, a | |
5814 | Printer MUST NOT produce printed output, but it MUST perform | |
5815 | other operations requested by a client. If a Printer had been | |
5816 | printing a job when the Printer was paused, the Printer MUST | |
5817 | resume printing that job when the Printer is no longer paused | |
5818 | and leave no evidence in the printed output of such a pause. | |
5819 | 'shutdown': Someone has removed a Printer object from service, and | |
5820 | the device may be powered down or physically removed. In this | |
5821 | state, a Printer object MUST NOT produce printed output, and | |
5822 | unless the Printer object is realized by a print server that is | |
5823 | ||
5824 | ||
5825 | ||
5826 | deBry, et al. Experimental [Page 104] | |
5827 | \f | |
5828 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5829 | ||
5830 | ||
5831 | still active, the Printer object MUST perform no other | |
5832 | operations requested by a client, including returning this | |
5833 | value. If a Printer object had been printing a job when it was | |
5834 | shutdown, the Printer NEED NOT resume printing that job when the | |
5835 | Printer is no longer shutdown. If the Printer resumes printing | |
5836 | such a job, it may leave evidence in the printed output of such | |
5837 | a shutdown, e.g. the part printed before the shutdown may be | |
5838 | printed a second time after the shutdown. | |
5839 | 'connecting-to-device': The Printer object has scheduled a job on | |
5840 | the output device and is in the process of connecting to a | |
5841 | shared network output device (and might not be able to actually | |
5842 | start printing the job for an arbitrarily long time depending on | |
5843 | the usage of the output device by other servers on the network). | |
5844 | 'timed-out': The server was able to connect to the output device | |
5845 | (or is always connected), but was unable to get a response from | |
5846 | the output device. | |
5847 | 'stopping': The Printer object is in the process of stopping the | |
5848 | device and will be stopped in a while. When the device is | |
5849 | stopped, the Printer object will change the Printer object's | |
5850 | state to 'stopped'. The 'stopping-warning' reason is never an | |
5851 | error, even for a Printer with a single output device. When an | |
5852 | output-device ceases accepting jobs, the Printer will have this | |
5853 | reason while the output device completes printing. | |
5854 | 'stopped-partly': When a Printer object controls more than one | |
5855 | output device, this reason indicates that one or more output | |
5856 | devices are stopped. If the reason is a report, fewer than half | |
5857 | of the output devices are stopped. If the reason is a warning, | |
5858 | fewer than all of the output devices are stopped. | |
5859 | 'toner-low': The device is low on toner. | |
5860 | 'toner-empty': The device is out of toner. | |
5861 | 'spool-area-full': The limit of persistent storage allocated for | |
5862 | spooling has been reached. | |
5863 | 'cover-open': One or more covers on the device are open. | |
5864 | 'interlock-open': One or more interlock devices on the printer are | |
5865 | unlocked. | |
5866 | 'door-open': One or more doors on the device are open. | |
5867 | 'input-tray-missing': One or more input trays are not in the | |
5868 | device. | |
5869 | 'media-low': At least one input tray is low on media. | |
5870 | 'media-empty': At least one input tray is empty. | |
5871 | 'output-tray-missing': One or more output trays are not in the | |
5872 | device | |
5873 | 'output-area-almost-full': One or more output area is almost full | |
5874 | (e.g. tray, stacker, collator). | |
5875 | 'output-area-full': One or more output area is full. (e.g. tray, | |
5876 | stacker, collator) | |
5877 | 'marker-supply-low': The device is low on at least one marker | |
5878 | supply. (e.g. toner, ink, ribbon) | |
5879 | ||
5880 | ||
5881 | ||
5882 | deBry, et al. Experimental [Page 105] | |
5883 | \f | |
5884 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5885 | ||
5886 | ||
5887 | 'marker-supply-empty: The device is out of at least one marker | |
5888 | supply. (e.g. toner, ink, ribbon) | |
5889 | 'marker-waste-almost-full': The device marker supply waste | |
5890 | receptacle is almost full. | |
5891 | 'marker-waste-full': The device marker supply waste receptacle is | |
5892 | full. | |
5893 | 'fuser-over-temp': The fuser temperature is above normal. | |
5894 | 'fuser-under-temp': The fuser temperature is below normal. | |
5895 | 'opc-near-eol': The optical photo conductor is near end of life. | |
5896 | 'opc-life-over': The optical photo conductor is no longer | |
5897 | functioning. | |
5898 | 'developer-low': The device is low on developer. | |
5899 | 'developer-empty: The device is out of developer. | |
5900 | 'interpreter-resource-unavailable': An interpreter resource is | |
5901 | unavailable (i.e. font, form) | |
5902 | ||
5903 | 4.4.12 printer-state-message (text(MAX)) | |
5904 | ||
5905 | This Printer attribute specifies the additional information about the | |
5906 | printer state and printer state reasons in human readable text. If | |
5907 | the Printer object supports this attribute, the Printer object MUST | |
5908 | be able to generate this message in any of the natural languages | |
5909 | identified by the Printer's "generated-natural-language-supported" | |
5910 | attribute (see the "attributes-natural-language" operation attribute | |
5911 | specified in Section 3.1.4.1). | |
5912 | ||
5913 | 4.4.13 operations-supported (1setOf type2 enum) | |
5914 | ||
5915 | This REQUIRED Printer attribute specifies the set of supported | |
5916 | operations for this Printer object and contained Job objects. All | |
5917 | 32-bit enum values for this attribute MUST NOT exceed 0x8FFF, since | |
5918 | these values are passed in two octets in each Protocol request | |
5919 | [RFC2565]. | |
5920 | ||
5921 | The following standard enum and "operation-id" (see section 3.1.2) | |
5922 | values are defined: | |
5923 | ||
5924 | Value Operation Name | |
5925 | ----------------- ------------------------------------- | |
5926 | ||
5927 | 0x0000 reserved, not used | |
5928 | 0x0001 reserved, not used | |
5929 | 0x0002 Print-Job | |
5930 | 0x0003 Print-URI | |
5931 | 0x0004 Validate-Job | |
5932 | 0x0005 Create-Job | |
5933 | 0x0006 Send-Document | |
5934 | 0x0007 Send-URI | |
5935 | ||
5936 | ||
5937 | ||
5938 | deBry, et al. Experimental [Page 106] | |
5939 | \f | |
5940 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5941 | ||
5942 | ||
5943 | 0x0008 Cancel-Job | |
5944 | 0x0009 Get-Job-Attributes | |
5945 | 0x000A Get-Jobs | |
5946 | 0x000B Get-Printer-Attributes | |
5947 | 0x000C-0x3FFF reserved for future operations | |
5948 | 0x4000-0x8FFF reserved for private extensions | |
5949 | ||
5950 | This allows for certain vendors to implement private extensions that | |
5951 | are guaranteed to not conflict with future registered extensions. | |
5952 | However, there is no guarantee that two or more private extensions | |
5953 | will not conflict. | |
5954 | ||
5955 | 4.4.14 charset-configured (charset) | |
5956 | ||
5957 | This REQUIRED Printer attribute identifies the charset that the | |
5958 | Printer object has been configured to represent 'text' and 'name' | |
5959 | Printer attributes that are set by the operator, system | |
5960 | administrator, or manufacturer, i.e., for "printer-name" (name), | |
5961 | "printer-location" (text), "printer-info" (text), and "printer-make- | |
5962 | and-model" (text). Therefore, the value of the Printer object's | |
5963 | "charset-configured" attribute MUST also be among the values of the | |
5964 | Printer object's "charset-supported" attribute. | |
5965 | ||
5966 | 4.4.15 charset-supported (1setOf charset) | |
5967 | ||
5968 | This REQUIRED Printer attribute identifies the set of charsets that | |
5969 | the Printer and contained Job objects support in attributes with | |
5970 | attribute syntax 'text' and 'name'. At least the value 'utf-8' MUST | |
5971 | be present, since IPP objects MUST support the UTF-8 [RFC2279] | |
5972 | charset. If a Printer object supports a charset, it means that for | |
5973 | all attributes of syntax 'text' and 'name' the IPP object MUST (1) | |
5974 | accept the charset in requests and return the charset in responses as | |
5975 | needed. | |
5976 | ||
5977 | If more charsets than UTF-8 are supported, the IPP object MUST | |
5978 | perform charset conversion between the charsets as described in | |
5979 | Section 3.2.1.2. | |
5980 | ||
5981 | 4.4.16 natural-language-configured (naturalLanguage) | |
5982 | ||
5983 | This REQUIRED Printer attribute identifies the natural language that | |
5984 | the Printer object has been configured to represent 'text' and 'name' | |
5985 | Printer attributes that are set by the operator, system | |
5986 | administrator, or manufacturer, i.e., for "printer-name" (name), | |
5987 | "printer-location" (text), "printer-info" (text), and "printer-make- | |
5988 | and-model" (text). When returning these Printer attributes, the | |
5989 | Printer object MAY return them in the configured natural language | |
5990 | specified by this attribute, instead of the natural language | |
5991 | ||
5992 | ||
5993 | ||
5994 | deBry, et al. Experimental [Page 107] | |
5995 | \f | |
5996 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
5997 | ||
5998 | ||
5999 | requested by the client in the "attributes-natural-language" | |
6000 | operation attribute. See Section 3.1.4.1 for the specification of | |
6001 | the OPTIONAL multiple natural language support. Therefore, the value | |
6002 | of the Printer object's "natural-language-configured" attribute MUST | |
6003 | also be among the values of the Printer object's "generated-natural- | |
6004 | language-supported" attribute. | |
6005 | ||
6006 | 4.4.17 generated-natural-language-supported (1setOf naturalLanguage) | |
6007 | ||
6008 | This REQUIRED Printer attribute identifies the natural language(s) | |
6009 | that the Printer object and contained Job objects support in | |
6010 | attributes with attribute syntax 'text' and 'name'. The natural | |
6011 | language(s) supported depends on implementation and/or configuration. | |
6012 | Unlike charsets, IPP objects MUST accept requests with any natural | |
6013 | language or any Natural Language Override whether the natural | |
6014 | language is supported or not. | |
6015 | ||
6016 | If a Printer object supports a natural language, it means that for | |
6017 | any of the attributes for which the Printer or Job object generates | |
6018 | messages, i.e., for the "job-state-message" and "printer-state- | |
6019 | message" attributes and Operation Messages (see Section 3.1.5) in | |
6020 | operation responses, the Printer and Job objects MUST be able to | |
6021 | generate messages in any of the Printer's supported natural | |
6022 | languages. See section 3.1.4 for the specification of 'text' and ' | |
6023 | name' attributes in operation requests and responses. | |
6024 | ||
6025 | Note: A Printer object that supports multiple natural languages, | |
6026 | often has separate catalogs of messages, one for each natural | |
6027 | language supported. | |
6028 | ||
6029 | 4.4.18 document-format-default (mimeMediaType) | |
6030 | ||
6031 | This REQUIRED Printer attribute identifies the document format that | |
6032 | the Printer object has been configured to assume if the client does | |
6033 | not supply a "document-format" operation attribute in any of the | |
6034 | operation requests that supply document data. The standard values | |
6035 | for this attribute are Internet Media types (sometimes called MIME | |
6036 | types). For further details see the description of the ' | |
6037 | mimeMediaType' attribute syntax in Section 4.1.9. | |
6038 | ||
6039 | 4.4.19 document-format-supported (1setOf mimeMediaType) | |
6040 | ||
6041 | This REQUIRED Printer attribute identifies the set of document | |
6042 | formats that the Printer object and contained Job objects can | |
6043 | support. For further details see the description of the ' | |
6044 | mimeMediaType' attribute syntax in Section 4.1.9. | |
6045 | ||
6046 | 4.4.20 printer-is-accepting-jobs (boolean) | |
6047 | ||
6048 | ||
6049 | ||
6050 | deBry, et al. Experimental [Page 108] | |
6051 | \f | |
6052 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6053 | ||
6054 | ||
6055 | This REQUIRED Printer attribute indicates whether the printer is | |
6056 | currently able to accept jobs, i.e., is accepting Print-Job, Print- | |
6057 | URI, and Create-Job requests. If the value is 'true', the printer is | |
6058 | accepting jobs. If the value is 'false', the Printer object is | |
6059 | currently rejecting any jobs submitted to it. In this case, the | |
6060 | Printer object returns the 'server-error-not-accepting-jobs' status | |
6061 | code. | |
6062 | ||
6063 | Note: This value is independent of the "printer-state" and "printer- | |
6064 | state-reasons" attributes because its value does not affect the | |
6065 | current job; rather it affects future jobs. This attribute may cause | |
6066 | the Printer to reject jobs when the "printer-state" is 'idle' or it | |
6067 | may cause the Printer object to accepts jobs when the "printer-state" | |
6068 | is 'stopped'. | |
6069 | ||
6070 | 4.4.21 queued-job-count (integer(0:MAX)) | |
6071 | ||
6072 | This RECOMMENDED Printer attribute contains a count of the number of | |
6073 | jobs that are either 'pending', 'processing', 'pending-held', or ' | |
6074 | processing-stopped' and is set by the Printer object. | |
6075 | ||
6076 | 4.4.22 printer-message-from-operator (text(127)) | |
6077 | ||
6078 | This Printer attribute provides a message from an operator, system | |
6079 | administrator or "intelligent" process to indicate to the end user | |
6080 | information or status of the printer, such as why it is unavailable | |
6081 | or when it is expected to be available. | |
6082 | ||
6083 | 4.4.23 color-supported (boolean) | |
6084 | ||
6085 | This Printer attribute identifies whether the device is capable of | |
6086 | any type of color printing at all, including highlight color. All | |
6087 | document instructions having to do with color are embedded within the | |
6088 | document PDL (none are external IPP attributes in IPP/1.0). | |
6089 | ||
6090 | Note: end-users are able to determine the nature and details of the | |
6091 | color support by querying the "printer-more-info-manufacturer" | |
6092 | Printer attribute. | |
6093 | ||
6094 | 4.4.24 reference-uri-schemes-supported (1setOf uriScheme) | |
6095 | ||
6096 | This Printer attribute specifies which URI schemes are supported for | |
6097 | use in the "document-uri" operation attribute of the Print-URI or | |
6098 | Send-URI operation. If a Printer object supports these optional | |
6099 | operations, it MUST support the "reference-uri-schemes-supported" | |
6100 | Printer attribute with at least the following schemed URI value: | |
6101 | ||
6102 | 'ftp': The Printer object will use an FTP 'get' operation as | |
6103 | ||
6104 | ||
6105 | ||
6106 | deBry, et al. Experimental [Page 109] | |
6107 | \f | |
6108 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6109 | ||
6110 | ||
6111 | defined in RFC 2228 [RFC2228] using FTP URLs as defined by | |
6112 | [RFC2396] and[RFC2316]. | |
6113 | ||
6114 | The Printer object MAY OPTIONALLY support other URI schemes (see | |
6115 | section 4.1.6). | |
6116 | ||
6117 | 4.4.25 pdl-override-supported (type2 keyword) | |
6118 | ||
6119 | This REQUIRED Printer attribute expresses the ability for a | |
6120 | particular Printer implementation to either attempt to override | |
6121 | document data instructions with IPP attributes or not. | |
6122 | ||
6123 | This attribute takes on the following values: | |
6124 | ||
6125 | - 'attempted': This value indicates that the Printer object | |
6126 | attempts to make the IPP attribute values take precedence over | |
6127 | embedded instructions in the document data, however there is no | |
6128 | guarantee. | |
6129 | ||
6130 | - 'not-attempted': This value indicates that the Printer object | |
6131 | makes no attempt to make the IPP attribute values take precedence | |
6132 | over embedded instructions in the document data. | |
6133 | ||
6134 | Section 15 contains a full description of how this attribute | |
6135 | interacts with and affects other IPP attributes, especially the | |
6136 | "ipp-attribute-fidelity" attribute. | |
6137 | ||
6138 | 4.4.26 printer-up-time (integer(1:MAX)) | |
6139 | ||
6140 | This REQUIRED Printer attribute indicates the amount of time (in | |
6141 | seconds) that this instance of this Printer implementation has been | |
6142 | up and running. This value is used to populate the Job attributes | |
6143 | "time-at-creation", "time-at-processing", and "time-at-completed". | |
6144 | These time values are all measured in seconds and all have meaning | |
6145 | only relative to this attribute, "printer-up-time". The value is a | |
6146 | monotonically increasing value starting from 1 when the Printer | |
6147 | object is started-up (initialized, booted, etc.). | |
6148 | ||
6149 | If the Printer object goes down at some value 'n', and comes back up, | |
6150 | the implementation MAY: | |
6151 | ||
6152 | 1. Know how long it has been down, and resume at some value greater | |
6153 | than 'n', or | |
6154 | 2. Restart from 1. | |
6155 | ||
6156 | In the first case, the Printer SHOULD not tweak any existing related | |
6157 | Job attributes ("time-at-creation", "time-at-processing", and "time- | |
6158 | at-completed"). In the second case, the Printer object SHOULD reset | |
6159 | ||
6160 | ||
6161 | ||
6162 | deBry, et al. Experimental [Page 110] | |
6163 | \f | |
6164 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6165 | ||
6166 | ||
6167 | those attributes to 0. If a client queries a time-related Job | |
6168 | attribute and finds the value to be 0, the client MUST assume that | |
6169 | the Job was submitted in some life other than the Printer's current | |
6170 | life. | |
6171 | ||
6172 | 4.4.27 printer-current-time (dateTime) | |
6173 | ||
6174 | This Printer attribute indicates the current absolute wall-clock | |
6175 | time. If an implementation supports this attribute, then a client | |
6176 | could calculate the absolute wall-clock time each Job's "time-at- | |
6177 | creation", "time-at-processing", and "time-at-completed" attributes | |
6178 | by using both "printer-up-time" and this attribute, "printer- | |
6179 | current-time". If an implementation does not support this attribute, | |
6180 | a client can only calculate the relative time of certain events based | |
6181 | on the REQUIRED "printer-up-time" attribute. | |
6182 | ||
6183 | 4.4.28 multiple-operation-time-out (integer(1:MAX)) | |
6184 | ||
6185 | This Printer attributes identifies the minimum time (in seconds) that | |
6186 | the Printer object waits for additional Send-Document or Send-URI | |
6187 | operations to follow a still-open multi-document Job object before | |
6188 | taking any recovery actions, such as the ones indicated in section | |
6189 | 3.3.1. | |
6190 | ||
6191 | It is RECOMMENDED that vendors supply a value for this attribute that | |
6192 | is between 60 and 240 seconds. An implementation MAY allow a system | |
6193 | administrator to set this attribute. If so, the system administrator | |
6194 | MAY be able to set values outside this range. | |
6195 | ||
6196 | 4.4.29 compression-supported (1setOf type3 keyword) | |
6197 | ||
6198 | This Printer attribute identifies the set of supported compression | |
6199 | algorithms for document data. Compression only applies to the | |
6200 | document data; compression does not apply to the encoding of the IPP | |
6201 | operation itself. The supported values are used to validate the | |
6202 | client supplied "compression" operation attributes in Print-Job, | |
6203 | Send-Document, and Send-URI requests. | |
6204 | ||
6205 | Standard values are : | |
6206 | ||
6207 | 'none': no compression is used. | |
6208 | 'deflate': ZIP public domain inflate/deflate) compression | |
6209 | technology | |
6210 | 'gzip' GNU zip compression technology described in RFC 1952 | |
6211 | [RFC1952]. | |
6212 | 'compress': UNIX compression technology | |
6213 | ||
6214 | 4.4.30 job-k-octets-supported (rangeOfInteger(0:MAX)) | |
6215 | ||
6216 | ||
6217 | ||
6218 | deBry, et al. Experimental [Page 111] | |
6219 | \f | |
6220 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6221 | ||
6222 | ||
6223 | This Printer attribute specifies the upper and lower bounds of total | |
6224 | sizes of jobs in K octets, i.e., in units of 1024 octets. The | |
6225 | supported values are used to validate the client supplied "job-k- | |
6226 | octets" operation attributes in create requests. The corresponding | |
6227 | job description attribute "job-k-octets" is defined in section | |
6228 | 4.3.17. | |
6229 | ||
6230 | 4.4.31 job-impressions-supported (rangeOfInteger(0:MAX)) | |
6231 | ||
6232 | This Printer attribute specifies the upper and lower bounds for the | |
6233 | number of impressions per job. The supported values are used to | |
6234 | validate the client supplied "job-impressions" operation attributes | |
6235 | in create requests. The corresponding job description attribute | |
6236 | "job-impressions" is defined in section 4.3.18. | |
6237 | ||
6238 | 4.4.32 job-media-sheets-supported (rangeOfInteger(0:MAX)) | |
6239 | ||
6240 | This Printer attribute specifies the upper and lower bounds for the | |
6241 | number of media sheets per job. The supported values are used to | |
6242 | validate the client supplied "job-media-sheets" operation attributes | |
6243 | in create requests. The corresponding Job attribute "job-media- | |
6244 | sheets" is defined in section 4.3.19. | |
6245 | ||
6246 | 5. Conformance | |
6247 | ||
6248 | This section describes conformance issues and requirements. This | |
6249 | document introduces model entities such as objects, operations, | |
6250 | attributes, attribute syntaxes, and attribute values. These | |
6251 | conformance sections describe the conformance requirements which | |
6252 | apply to these model entities. | |
6253 | ||
6254 | 5.1 Client Conformance Requirements | |
6255 | ||
6256 | A conforming client MUST support all REQUIRED operations as defined | |
6257 | in this document. For each attribute included in an operation | |
6258 | request, a conforming client MUST supply a value whose type and value | |
6259 | syntax conforms to the requirements of the Model document as | |
6260 | specified in Sections 3 and 4. A conforming client MAY supply any | |
6261 | registered extensions and/or private extensions in an operation | |
6262 | request, as long as they meet the requirements in Section 6. | |
6263 | ||
6264 | Otherwise, there are no conformance requirements placed on the user | |
6265 | interfaces provided by IPP clients or their applications. For | |
6266 | example, one application might not allow an end user to submit | |
6267 | multiple documents per job, while another does. One application | |
6268 | might first query a Printer object in order to supply a graphical | |
6269 | user interface (GUI) dialogue box with supported and default values | |
6270 | whereas a different implementation might not. | |
6271 | ||
6272 | ||
6273 | ||
6274 | deBry, et al. Experimental [Page 112] | |
6275 | \f | |
6276 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6277 | ||
6278 | ||
6279 | When sending a request, an IPP client NEED NOT supply any attributes | |
6280 | that are indicated as OPTIONALLY supplied by the client. | |
6281 | ||
6282 | A client MUST be able to accept any of the attribute syntaxes defined | |
6283 | in Section 4.1, including their full range, that may be returned to | |
6284 | it in a response from a Printer object. In particular for each | |
6285 | attribute that the client supports whose attribute syntax is 'text', | |
6286 | the client MUST accept and process both the 'textWithoutLanguage' and | |
6287 | 'textWithLanguage' forms. Similarly, for each attribute that the | |
6288 | client supports whose attribute syntax is 'name', the client MUST | |
6289 | accept and process both the 'nameWithoutLanguage' and ' | |
6290 | nameWithLanguage' forms. For presentation purposes, truncation of | |
6291 | long attribute values is not recommended. A recommended approach | |
6292 | would be for the client implementation to allow the user to scroll | |
6293 | through long attribute values. | |
6294 | ||
6295 | A query response may contain attribute groups, attributes, and values | |
6296 | that the client does not expect. Therefore, a client implementation | |
6297 | MUST gracefully handle such responses and not refuse to inter-operate | |
6298 | with a conforming Printer that is returning extended registered or | |
6299 | private attributes and/or attribute values that conform to Section 6. | |
6300 | Clients may choose to ignore any parameters, attributes, or values | |
6301 | that they do not understand. | |
6302 | ||
6303 | 5.2 IPP Object Conformance Requirements | |
6304 | ||
6305 | This section specifies the conformance requirements for conforming | |
6306 | implementations with respect to objects, operations, and attributes. | |
6307 | ||
6308 | 5.2.1 Objects | |
6309 | ||
6310 | Conforming implementations MUST implement all of the model objects as | |
6311 | defined in this specification in the indicated sections: | |
6312 | ||
6313 | Section 2.1 - Printer Object | |
6314 | Section 2.2 - Job Object | |
6315 | ||
6316 | 5.2.2 Operations | |
6317 | ||
6318 | Conforming IPP object implementations MUST implement all of the | |
6319 | REQUIRED model operations, including REQUIRED responses, as defined | |
6320 | in this specification in the indicated sections: | |
6321 | ||
6322 | For a Printer object: | |
6323 | Print-Job (section 3.2.1) REQUIRED | |
6324 | Print-URI (section 3.2.2) OPTIONAL | |
6325 | Validate-Job (section 3.2.3) REQUIRED | |
6326 | Create-Job (section 3.2.4) OPTIONAL | |
6327 | ||
6328 | ||
6329 | ||
6330 | deBry, et al. Experimental [Page 113] | |
6331 | \f | |
6332 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6333 | ||
6334 | ||
6335 | Get-Printer-Attributes (section 3.2.5) REQUIRED | |
6336 | Get-Jobs (section 3.2.6) REQUIRED | |
6337 | ||
6338 | For a Job object: | |
6339 | Send-Document (section 3.3.1) OPTIONAL | |
6340 | Send-URI (section 3.3.2) OPTIONAL | |
6341 | Cancel-Job (section 3.3.3) REQUIRED | |
6342 | Get-Job-Attributes (section 3.3.4) REQUIRED | |
6343 | ||
6344 | Conforming IPP objects MUST support all REQUIRED operation attributes | |
6345 | and all values of such attributes if so indicated in the description. | |
6346 | Conforming IPP objects MUST ignore all unsupported or unknown | |
6347 | operation attributes or operation attribute groups received in a | |
6348 | request, but MUST reject a request that contains a supported | |
6349 | operation attribute that contains an unsupported value. | |
6350 | ||
6351 | The following section on object attributes specifies the support | |
6352 | required for object attributes. | |
6353 | ||
6354 | 5.2.3 IPP Object Attributes | |
6355 | ||
6356 | Conforming IPP objects MUST support all of the REQUIRED object | |
6357 | attributes, as defined in this specification in the indicated | |
6358 | sections. | |
6359 | ||
6360 | If an object supports an attribute, it MUST support only those values | |
6361 | specified in this document or through the extension mechanism | |
6362 | described in section 5.2.4. It MAY support any non-empty subset of | |
6363 | these values. That is, it MUST support at least one of the specified | |
6364 | values and at most all of them. | |
6365 | ||
6366 | 5.2.4 Extensions | |
6367 | ||
6368 | A conforming IPP object MAY support registered extensions and private | |
6369 | extensions, as long as they meet the requirements specified in | |
6370 | Section 6. | |
6371 | ||
6372 | For each attribute included in an operation response, a conforming | |
6373 | IPP object MUST return a value whose type and value syntax conforms | |
6374 | to the requirement of the Model document as specified in Sections 3 | |
6375 | and 4. | |
6376 | ||
6377 | ||
6378 | ||
6379 | ||
6380 | ||
6381 | ||
6382 | ||
6383 | ||
6384 | ||
6385 | ||
6386 | deBry, et al. Experimental [Page 114] | |
6387 | \f | |
6388 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6389 | ||
6390 | ||
6391 | 5.2.5 Attribute Syntaxes | |
6392 | ||
6393 | An IPP object MUST be able to accept any of the attribute syntaxes | |
6394 | defined in Section 4.1, including their full range, in any operation | |
6395 | in which a client may supply attributes or the system administrator | |
6396 | may configure attributes (by means outside the scope of IPP/1.0). In | |
6397 | particular for each attribute that the IPP object supports whose | |
6398 | attribute syntax is 'text', the IPP object MUST accept and process | |
6399 | both the 'textWithoutLanguage' and 'textWithLanguage' forms. | |
6400 | Similarly, for each attribute that the IPP object supports whose | |
6401 | attribute syntax is 'name', the IPP object MUST accept and process | |
6402 | both the 'nameWithoutLanguage' and 'nameWithLanguage' forms. | |
6403 | Furthermore, an IPP object MUST return attributes to the client in | |
6404 | operation responses that conform to the syntax specified in Section | |
6405 | 4.1, including their full range if supplied previously by a client. | |
6406 | ||
6407 | 5.3 Charset and Natural Language Requirements | |
6408 | ||
6409 | All clients and IPP objects MUST support the 'utf-8' charset as | |
6410 | defined in section 4.1.7. | |
6411 | ||
6412 | IPP objects MUST be able to accept any client request which correctly | |
6413 | uses the "attributes-natural-language" operation attribute or the | |
6414 | Natural Language Override mechanism on any individual attribute | |
6415 | whether or not the natural language is supported by the IPP object. | |
6416 | If an IPP object supports a natural language, then it MUST be able to | |
6417 | translate (perhaps by table lookup) all generated 'text' or 'name' | |
6418 | attribute values into one of the supported languages (see section | |
6419 | 3.1.4). That is, the IPP object that supports a natural language | |
6420 | NEED NOT be a general purpose translator of any arbitrary 'text' or ' | |
6421 | name' value supplied by the client into that natural language. | |
6422 | However, the object MUST be able to translate (automatically | |
6423 | generate) any of its own attribute values and messages into that | |
6424 | natural language. | |
6425 | ||
6426 | 5.4 Security Conformance Requirements | |
6427 | ||
6428 | Conforming IPP Printer objects MAY support Secure Socket Layer | |
6429 | Version 3 (SSL3) [SSL] access, support access without SSL3 or support | |
6430 | both means of access. | |
6431 | ||
6432 | Conforming IPP clients SHOULD support SSL3 access and non-SSL3 | |
6433 | access. Note: This client requirement to support both means that | |
6434 | conforming IPP clients will be able to inter-operate with any IPP | |
6435 | Printer object. | |
6436 | ||
6437 | ||
6438 | ||
6439 | ||
6440 | ||
6441 | ||
6442 | deBry, et al. Experimental [Page 115] | |
6443 | \f | |
6444 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6445 | ||
6446 | ||
6447 | For a detailed discussion of security considerations and the IPP | |
6448 | application security profile required for SSL3 support, see section | |
6449 | 8. | |
6450 | ||
6451 | 6. IANA Considerations (registered and private extensions) | |
6452 | ||
6453 | This section describes how IPP can be extended to allow the following | |
6454 | registered and private extensions to IPP: | |
6455 | ||
6456 | 1. keyword attribute values | |
6457 | 2. enum attribute values | |
6458 | 3. attributes | |
6459 | 4. attribute syntaxes | |
6460 | 5. operations | |
6461 | 6. attribute groups | |
6462 | 7. status codes | |
6463 | ||
6464 | Extensions registered for use with IPP/1.0 are OPTIONAL for client | |
6465 | and IPP object conformance to the IPP/1.0 Model specification. | |
6466 | ||
6467 | These extension procedures are aligned with the guidelines as set | |
6468 | forth by the IESG [RFC2434]. Section 11 describes how to propose new | |
6469 | registrations for consideration. IANA will reject registration | |
6470 | proposals that leave out required information or do not follow the | |
6471 | appropriate format described in Section 11. IPP/1.0 may also be | |
6472 | extended by an appropriate RFC that specifies any of the above | |
6473 | extensions. | |
6474 | ||
6475 | 6.1 Typed 'keyword' and 'enum' Extensions | |
6476 | ||
6477 | IPP allows for 'keyword' and 'enum' extensions (see sections 4.1.2.3 | |
6478 | and 4.1.4). This document uses prefixes to the 'keyword' and 'enum' | |
6479 | basic attribute syntax type in order to communicate extra information | |
6480 | to the reader through its name. This extra information is not | |
6481 | represented in the protocol because it is unimportant to a client or | |
6482 | Printer object. The list below describes the prefixes and their | |
6483 | meaning. | |
6484 | ||
6485 | "type1": The IPP specification must be revised to add a new | |
6486 | keyword or a new enum. No private keywords or enums are | |
6487 | allowed. | |
6488 | ||
6489 | "type2": Implementers can, at any time, add new keyword or enum | |
6490 | values by proposing the complete specification to IANA: | |
6491 | ||
6492 | iana@iana.org | |
6493 | ||
6494 | ||
6495 | ||
6496 | ||
6497 | ||
6498 | deBry, et al. Experimental [Page 116] | |
6499 | \f | |
6500 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6501 | ||
6502 | ||
6503 | IANA will forward the registration proposal to the IPP | |
6504 | Designated Expert who will review the proposal with a mailing | |
6505 | list that the Designated Expert keeps for this purpose. | |
6506 | Initially, that list will be the mailing list used by the IPP | |
6507 | WG: | |
6508 | ||
6509 | ipp@pwg.org | |
6510 | ||
6511 | even after the IPP WG is disbanded as permitted by [RFC2434]. | |
6512 | The IPP Designated Expert is appointed by the IESG Area Director | |
6513 | responsible for IPP, according to [RFC2434]. | |
6514 | ||
6515 | When a type2 keyword or enum is approved, the IPP Designated | |
6516 | Expert becomes the point of contact for any future maintenance | |
6517 | that might be required for that registration. | |
6518 | ||
6519 | "type3": Implementers can, at any time, add new keyword and enum | |
6520 | values by submitting the complete specification to IANA as for | |
6521 | type2 who will forward the proposal to the IPP Designated | |
6522 | Expert. While no additional technical review is required, the | |
6523 | IPP Designated Expert may, at his/her discretion, forward the | |
6524 | proposal to the same mailing list as for type2 registrations for | |
6525 | advice and comment. | |
6526 | ||
6527 | When a type3 keyword or enum is approved by the IPP Designated | |
6528 | Expert, the original proposer becomes the point of contact for | |
6529 | any future maintenance that might be required for that | |
6530 | registration. | |
6531 | ||
6532 | For type2 and type3 keywords, the proposer includes the name of the | |
6533 | keyword in the registration proposal and the name is part of the | |
6534 | technical review. | |
6535 | ||
6536 | After type2 and type3 enums specifications are approved, the IPP | |
6537 | Designated Expert in consultation with IANA assigns the next | |
6538 | available enum number for each enum value. | |
6539 | ||
6540 | IANA will publish approved type2 and type3 keyword and enum | |
6541 | attributes value registration specifications in: | |
6542 | ||
6543 | ftp.isi.edu/iana/assignments/ipp/attribute-values/xxx/yyy.txt | |
6544 | ||
6545 | where xxx is the attribute name that specifies the initial values and | |
6546 | yyy.txt is a descriptive file name that contains one or more enums or | |
6547 | keywords approved at the same time. For example, if several | |
6548 | additional enums for stapling are approved for use with the | |
6549 | ||
6550 | ||
6551 | ||
6552 | ||
6553 | ||
6554 | deBry, et al. Experimental [Page 117] | |
6555 | \f | |
6556 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6557 | ||
6558 | ||
6559 | "finishings" attribute (and "finishings-default" and "finishings- | |
6560 | supported" attributes), IANA will publish the additional values in | |
6561 | the file: | |
6562 | ||
6563 | ftp.isi.edu/iana/assignments/ipp/attribute- | |
6564 | values/finishings/stapling.txt | |
6565 | ||
6566 | Note: Some attributes are defined to be: 'type3 keywords' | 'name' | |
6567 | which allows for attribute values to be extended by a site | |
6568 | administrator with administrator defined names. Such names are not | |
6569 | registered with IANA. | |
6570 | ||
6571 | By definition, each of the three types above assert some sort of | |
6572 | registry or review process in order for extensions to be considered | |
6573 | valid. Each higher numbered level (1, 2, 3) tends to be decreasingly | |
6574 | less stringent than the previous level. Therefore, any typeN value | |
6575 | MAY be registered using a process for some typeM where M is less than | |
6576 | N, however such registration is NOT REQUIRED. For example, a type3 | |
6577 | value MAY be registered in a type 1 manner (by being included in a | |
6578 | future version of an IPP specification), however, it is NOT REQUIRED. | |
6579 | ||
6580 | This specification defines keyword and enum values for all of the | |
6581 | above types, including type3 keywords. | |
6582 | ||
6583 | For private (unregistered) keyword extensions, implementers SHOULD | |
6584 | use keywords with a suitable distinguishing prefix, such as "xxx-" | |
6585 | where xxx is the (lowercase) fully qualified company name registered | |
6586 | with IANA for use in domain names [RFC1035]. For example, if the | |
6587 | company XYZ Corp. had obtained the domain name "XYZ.com", then a | |
6588 | private keyword 'abc' would be: 'xyz.com-abc'. | |
6589 | ||
6590 | Note: RFC 1035 [RFC1035] indicates that while upper and lower case | |
6591 | letters are allowed in domain names, no significance is attached to | |
6592 | the case. That is, two names with the same spelling but different | |
6593 | case are to be treated as if identical. Also, the labels in a domain | |
6594 | name must follow the rules for ARPANET host names: They must start | |
6595 | with a letter, end with a letter or digit, and have as interior | |
6596 | characters only letters, digits, and hyphen. Labels must be 63 | |
6597 | characters or less. Labels are separated by the "." character. | |
6598 | ||
6599 | For private (unregistered) enum extension, implementers MUST use | |
6600 | values in the reserved integer range which is 2**30 to 2**31-1. | |
6601 | ||
6602 | ||
6603 | ||
6604 | ||
6605 | ||
6606 | ||
6607 | ||
6608 | ||
6609 | ||
6610 | deBry, et al. Experimental [Page 118] | |
6611 | \f | |
6612 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6613 | ||
6614 | ||
6615 | 6.2 Attribute Extensibility | |
6616 | ||
6617 | Attribute names are type2 keywords. Therefore, new attributes may be | |
6618 | registered and have the same status as attributes in this document by | |
6619 | following the type2 extension rules. For private (unregistered) | |
6620 | attribute extensions, implementers SHOULD use keywords with a | |
6621 | suitable distinguishing prefix as described in Section 6.1. | |
6622 | ||
6623 | IANA will publish approved attribute registration specifications as | |
6624 | separate files: | |
6625 | ||
6626 | ftp.isi.edu/iana/assignments/ipp/attributes/xxx-yyy.txt | |
6627 | ||
6628 | where "xxx-yyy" is the new attribute name. | |
6629 | ||
6630 | If a new Printer object attribute is defined and its values can be | |
6631 | affected by a specific document format, its specification needs to | |
6632 | contain the following sentence: | |
6633 | ||
6634 | "The value of this attribute returned in a Get-Printer-Attributes | |
6635 | response MAY depend on the "document-format" attribute supplied | |
6636 | (see Section 3.2.5.1)." | |
6637 | ||
6638 | If the specification does not, then its value in the Get-Printer- | |
6639 | Attributes response MUST NOT depend on the "document-format" supplied | |
6640 | in the request. When a new Job Template attribute is registered, the | |
6641 | value of the Printer attributes MAY vary with "document-format" | |
6642 | supplied in the request without the specification having to indicate | |
6643 | so. | |
6644 | ||
6645 | 6.3 Attribute Syntax Extensibility | |
6646 | ||
6647 | Attribute syntaxes are like type2 enums. Therefore, new attribute | |
6648 | syntaxes may be registered and have the same status as attribute | |
6649 | syntaxes in this document by following the type2 extension rules | |
6650 | described in Section 6.1. The value codes that identify each of the | |
6651 | attribute syntaxes are assigned in the Encoding and Transport | |
6652 | specification [RFC2565], including a designated range for private, | |
6653 | experimental use. | |
6654 | ||
6655 | For attribute syntaxes, the IPP Designated Expert in consultation | |
6656 | with IANA assigns the next attribute syntax code in the appropriate | |
6657 | range as specified in [RFC2565]. IANA will publish approved | |
6658 | attribute syntax registration specifications as separate files: | |
6659 | ||
6660 | ftp.isi.edu/iana/assignments/ipp/attribute-syntaxes/xxx-yyy.txt | |
6661 | ||
6662 | where 'xxx-yyy' is the new attribute syntax name. | |
6663 | ||
6664 | ||
6665 | ||
6666 | deBry, et al. Experimental [Page 119] | |
6667 | \f | |
6668 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6669 | ||
6670 | ||
6671 | 6.4 Operation Extensibility | |
6672 | ||
6673 | Operations may also be registered following the type2 procedures | |
6674 | described in Section 6.1, though major new operations will usually be | |
6675 | done by a new standards track RFC that augments this document. For | |
6676 | private (unregistered) operation extensions, implementers MUST use | |
6677 | the range for the "operation-id" in requests specified in Section | |
6678 | 4.4.13 "operations-supported" Printer attribute. | |
6679 | ||
6680 | For operations, the IPP Designated Expert in consultation with IANA | |
6681 | assigns the next operation-id code as specified in Section 4.4.13. | |
6682 | IANA will publish approved operation registration specifications as | |
6683 | separate files: | |
6684 | ||
6685 | ftp.isi.edu/iana/assignments/ipp/operations/Xxx-Yyy.txt | |
6686 | ||
6687 | where "Xxx-Yyy" is the new operation name. | |
6688 | ||
6689 | 6.5 Attribute Groups | |
6690 | ||
6691 | Attribute groups passed in requests and responses may be registered | |
6692 | following the type2 procedures described in Section 6.1. The tags | |
6693 | that identify each of the attribute groups are assigned in [RFC2565]. | |
6694 | ||
6695 | For attribute groups, the IPP Designated Expert in consultation with | |
6696 | IANA assigns the next attribute group tag code in the appropriate | |
6697 | range as specified in [RFC2565]. IANA will publish approved | |
6698 | attribute group registration specifications as separate files: | |
6699 | ||
6700 | ftp.isi.edu/iana/assignments/ipp/attribute-group-tags/xxx-yyy- | |
6701 | tag.txt | |
6702 | ||
6703 | where 'xxx-yyy-tag' is the new attribute group tag name. | |
6704 | ||
6705 | 6.6 Status Code Extensibility | |
6706 | ||
6707 | Operation status codes may also be registered following the type2 | |
6708 | procedures described in Section 6.1. The values for status codes are | |
6709 | allocated in ranges as specified in Section 13 for each status code | |
6710 | class: | |
6711 | ||
6712 | "informational" - Request received, continuing process | |
6713 | "successful" - The action was successfully received, understood, | |
6714 | and accepted | |
6715 | "redirection" - Further action must be taken in order to complete | |
6716 | the request | |
6717 | "client-error" - The request contains bad syntax or cannot be | |
6718 | fulfilled | |
6719 | ||
6720 | ||
6721 | ||
6722 | deBry, et al. Experimental [Page 120] | |
6723 | \f | |
6724 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6725 | ||
6726 | ||
6727 | "server-error" - The IPP object failed to fulfill an apparently | |
6728 | valid request | |
6729 | ||
6730 | For private (unregistered) operation status code extensions, | |
6731 | implementers MUST use the top of each range as specified in Section | |
6732 | 13. | |
6733 | ||
6734 | For operation status codes, the IPP Designated Expert in consultation | |
6735 | with IANA assigns the next status code in the appropriate class range | |
6736 | as specified in Section 13. IANA will publish approved status code | |
6737 | registration specifications as separate files: | |
6738 | ||
6739 | ftp.isi.edu/iana/assignments/ipp/status-codes/xxx-yyy.txt | |
6740 | ||
6741 | where "xxx-yyy" is the new operation status code keyword. | |
6742 | ||
6743 | 6.7 Registration of MIME types/sub-types for document-formats | |
6744 | ||
6745 | The "document-format" attribute's syntax is 'mimeMediaType'. This | |
6746 | means that valid values are Internet Media Types (see Section 4.1.9). | |
6747 | RFC 2045 [RFC2045] defines the syntax for valid Internet media types. | |
6748 | IANA is the registry for all Internet media types. | |
6749 | ||
6750 | 6.8 Registration of charsets for use in 'charset' attribute values | |
6751 | ||
6752 | The "attributes-charset" attribute's syntax is 'charset'. This means | |
6753 | that valid values are charsets names. When a charset in the IANA | |
6754 | registry has more than one name (alias), the name labeled as | |
6755 | "(preferred MIME name)", if present, MUST be used (see Section | |
6756 | 4.1.7). IANA is the registry for charsets following the procedures | |
6757 | of [RFC2278]. | |
6758 | ||
6759 | 7. Internationalization Considerations | |
6760 | ||
6761 | Some of the attributes have values that are text strings and names | |
6762 | which are intended for human understanding rather than machine | |
6763 | understanding (see the 'text' and 'name' attribute syntaxes in | |
6764 | Sections 4.1.1 and 4.1.2). | |
6765 | ||
6766 | In each operation request, the client | |
6767 | ||
6768 | - identifies the charset and natural language of the request which | |
6769 | affects each supplied 'text' and 'name' attribute value, and | |
6770 | - requests the charset and natural language for attributes returned | |
6771 | by the IPP object in operation responses (as described in Section | |
6772 | 3.1.4.1). | |
6773 | ||
6774 | ||
6775 | ||
6776 | ||
6777 | ||
6778 | deBry, et al. Experimental [Page 121] | |
6779 | \f | |
6780 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6781 | ||
6782 | ||
6783 | In addition, the client MAY separately and individually identify the | |
6784 | Natural Language Override of a supplied 'text' or 'name' attribute | |
6785 | using the 'textWithLanguage' and 'nameWithLanguage' technique | |
6786 | described section 4.1.1.2 and 4.1.2.2 respectively. | |
6787 | ||
6788 | All IPP objects MUST support the UTF-8 [RFC2279] charset in all ' | |
6789 | text' and 'name' attributes supported. If an IPP object supports | |
6790 | more than the UTF-8 charset, the object MUST convert between them in | |
6791 | order to return the requested charset to the client according to | |
6792 | Section 3.1.4.2. If an IPP object supports more than one natural | |
6793 | language, the object SHOULD return 'text' and 'name' values in the | |
6794 | natural language requested where those values are generated by the | |
6795 | Printer (see Section 3.1.4.1). | |
6796 | ||
6797 | For Printers that support multiple charsets and/or multiple natural | |
6798 | languages in 'text' and 'name' attributes, different jobs may have | |
6799 | been submitted in differing charsets and/or natural languages. All | |
6800 | responses MUST be returned in the charset requested by the client. | |
6801 | However, the Get-Jobs operation uses the 'textWithLanguage' and ' | |
6802 | nameWithLanguage' mechanism to identify the differing natural | |
6803 | languages with each job attribute returned. | |
6804 | ||
6805 | The Printer object also has configured charset and natural language | |
6806 | attributes. The client can query the Printer object to determine | |
6807 | the list of charsets and natural languages supported by the Printer | |
6808 | object and what the Printer object's configured values are. See the | |
6809 | "charset-configured", "charset-supported", "natural-language- | |
6810 | configured", and "generated-natural-language-supported" Printer | |
6811 | description attributes for more details. | |
6812 | ||
6813 | The "charset-supported" attributed identifies the supported charsets. | |
6814 | If a charset is supported, the IPP object MUST be capable of | |
6815 | converting to and from that charset into any other supported charset. | |
6816 | In many cases, an IPP object will support only one charset and it | |
6817 | MUST be the UTF-8 charset. | |
6818 | ||
6819 | The "charset-configured" attribute identifies the one supported | |
6820 | charset which is the native charset given the current configuration | |
6821 | of the IPP object (administrator defined). | |
6822 | ||
6823 | The "generated-natural-language-supported" attribute identifies the | |
6824 | set of supported natural languages for generated messages; it is not | |
6825 | related to the set of natural languages that must be accepted for | |
6826 | client supplied 'text' and 'name' attributes. For client supplied ' | |
6827 | text' and 'name' attributes, an IPP object MUST accept ALL supplied | |
6828 | natural languages. Just because a Printer object is currently | |
6829 | ||
6830 | ||
6831 | ||
6832 | ||
6833 | ||
6834 | deBry, et al. Experimental [Page 122] | |
6835 | \f | |
6836 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6837 | ||
6838 | ||
6839 | configured to support 'en-us' natural language does not mean that the | |
6840 | Printer object should reject a job if the client supplies a job name | |
6841 | that is in 'fr-ca'. | |
6842 | ||
6843 | The "natural-language-configured" attribute identifies the one | |
6844 | supported natural language for generated messages which is the native | |
6845 | natural language given the current configuration of the IPP object | |
6846 | (administrator defined). | |
6847 | ||
6848 | Attributes of type 'text' and 'name' are populated from different | |
6849 | sources. These attributes can be categorized into following groups | |
6850 | (depending on the source of the attribute): | |
6851 | ||
6852 | 1. Some attributes are supplied by the client (e.g., the client | |
6853 | supplied "job-name", "document-name", and "requesting-user-name" | |
6854 | operation attributes along with the corresponding Job object's | |
6855 | "job-name" and "job-originating-user-name" attributes). The IPP | |
6856 | object MUST accept these attributes in any natural language no | |
6857 | matter what the set of supported languages for generated | |
6858 | messages | |
6859 | 2. Some attributes are supplied by the system administrator (e.g., | |
6860 | the Printer object's "printer-name" and "printer-location" | |
6861 | attributes). These too can be in any natural language. If the | |
6862 | natural language for these attributes is different than what a | |
6863 | client requests, then they must be reported using the Natural | |
6864 | Language Override mechanism. | |
6865 | 3. Some attributes are supplied by the device manufacturer (e.g., | |
6866 | the Printer object's "printer-make-and-model" attribute). These | |
6867 | too can be in any natural language. If the natural language for | |
6868 | these attributes is different than what a client requests, then | |
6869 | they must be reported using the Natural Language Override | |
6870 | mechanism. | |
6871 | 4. Some attributes are supplied by the operator (e.g., the Job | |
6872 | object's "job-message-from-operator" attribute). These too can | |
6873 | be in any natural language. If the natural language for these | |
6874 | attributes is different than what a client requests, then they | |
6875 | must be reported using the Natural Language Override mechanism. | |
6876 | 5. Some attributes are generated by the IPP object (e.g., the Job | |
6877 | object's "job-state-message" attribute, the Printer object's | |
6878 | "printer-state-message" attribute, and the "status-message" | |
6879 | operation attribute). These attributes can only be in one of | |
6880 | the "generated-natural-language-supported" natural languages. | |
6881 | If a client requests some natural language for these attributes | |
6882 | other than one of the supported values, the IPP object SHOULD | |
6883 | respond using the value of the "natural-language-configured" | |
6884 | attribute (using the Natural Language Override mechanism if | |
6885 | needed). | |
6886 | ||
6887 | ||
6888 | ||
6889 | ||
6890 | deBry, et al. Experimental [Page 123] | |
6891 | \f | |
6892 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6893 | ||
6894 | ||
6895 | The 'text' and 'name' attributes specified in this version of this | |
6896 | document (additional ones will be registered according to the | |
6897 | procedures in Section 6) are: | |
6898 | ||
6899 | Attributes Source | |
6900 | -------------------------- ---------- | |
6901 | Operation Attributes | |
6902 | job-name (name) client | |
6903 | document-name (name) client | |
6904 | requesting-user-name (name) client | |
6905 | status-message Job or Printer object | |
6906 | ||
6907 | Job Template Attributes: | |
6908 | job-hold-until) client matches administrator-configured | |
6909 | (keyword | name | |
6910 | job-hold-until-default client matches administrator-configured | |
6911 | (keyword | name) | |
6912 | job-hold-until-supported client matches administrator-configured | |
6913 | (keyword | name) | |
6914 | job-sheets client matches administrator-configured | |
6915 | (keyword | name) | |
6916 | job-sheets-default client matches administrator-configured | |
6917 | (keyword | name) | |
6918 | job-sheets-supported client matches administrator-configured | |
6919 | (keyword | name) | |
6920 | media client matches administrator-configured | |
6921 | (keyword | name) | |
6922 | media-default client matches administrator-configured | |
6923 | (keyword | name) | |
6924 | media-supported client matches administrator-configured | |
6925 | (keyword | name) | |
6926 | media-ready client matches administrator-configured | |
6927 | (keyword | name) | |
6928 | ||
6929 | Job Description Attributes: | |
6930 | job-name (name) client or Printer object | |
6931 | job-originating-user-name (name) Printer object | |
6932 | job-state-message (text) Job or Printer object | |
6933 | output-device-assigned (name(127)) administrator | |
6934 | job-message-from-operator (text(127)) operator | |
6935 | ||
6936 | Printer Description Attributes: | |
6937 | printer-name (name(127)) administrator | |
6938 | printer-location (text(127)) administrator | |
6939 | printer-info (text(127)) administrator | |
6940 | printer-make-and-model (text(127)) administrator or manufacturer | |
6941 | printer-state-message (text) Printer object | |
6942 | printer-message-from-operator (text(127)) operator | |
6943 | ||
6944 | ||
6945 | ||
6946 | deBry, et al. Experimental [Page 124] | |
6947 | \f | |
6948 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
6949 | ||
6950 | ||
6951 | 8. Security Considerations | |
6952 | ||
6953 | Some IPP objects MAY be deployed over protocol stacks that support | |
6954 | Secure Socket Layer Version 3 (SSL3) [SSL]. Note: SSL3 is not an | |
6955 | IETF standards track specification. Other IPP objects MAY be | |
6956 | deployed over protocol stacks that do not support SSL3. Some IPP | |
6957 | objects MAY be deployed over both types of protocol stacks. Those | |
6958 | IPP objects that support SSL3, are capable of supporting mutual | |
6959 | authentication as well as privacy of messages via multiple encryption | |
6960 | schemes. An important point about security related information for | |
6961 | SSL3 access to an IPP object, is that the security-related parameters | |
6962 | (authentication, encryption keys, etc.) are "out-of-band" to the | |
6963 | actual IPP protocol. | |
6964 | ||
6965 | An IPP object that does not support SSL3 MAY elect to support a | |
6966 | transport layer that provides other security mechanisms. For | |
6967 | example, in a mapping of IPP over HTTP/1.1 [RFC2565], if the IPP | |
6968 | object does not support SSL3, HTTP still allows for client | |
6969 | authentication using Digest Access Authentication (DAA) [RFC2069]. | |
6970 | ||
6971 | It is difficult to anticipate the security risks that might exist in | |
6972 | any given IPP environment. For example, if IPP is used within a given | |
6973 | corporation over a private network, the risks of exposing document | |
6974 | data may be low enough that the corporation will choose not to use | |
6975 | encryption on that data. However, if the connection between the | |
6976 | client and the IPP object is over a public network, the client may | |
6977 | wish to protect the content of the information during transmission | |
6978 | through the network with encryption. | |
6979 | ||
6980 | Furthermore, the value of the information being printed may vary from | |
6981 | one IPP environment to the next. Printing payroll checks, for | |
6982 | example, would have a different value than printing public | |
6983 | information from a file. There is also the possibly of denial-of- | |
6984 | service attacks, but denial-of-service attacks against printing | |
6985 | resources are not well understood and there is no published | |
6986 | precedents regarding this scenario. | |
6987 | ||
6988 | Once the authenticated identity of the requester has been supplied to | |
6989 | the IPP object, the object uses that identity to enforce any | |
6990 | authorization policy that might be in place. For example, one site's | |
6991 | policy might be that only the job owner is allowed to cancel a job. | |
6992 | The details and mechanisms to set up a particular access control | |
6993 | policy are not part of IPP/1.0, and must be established via some | |
6994 | other type of administrative or access control framework. However, | |
6995 | there are operation status codes that allow an IPP server to return | |
6996 | information back to a client about any potential access control | |
6997 | violations for an IPP object. | |
6998 | ||
6999 | ||
7000 | ||
7001 | ||
7002 | deBry, et al. Experimental [Page 125] | |
7003 | \f | |
7004 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7005 | ||
7006 | ||
7007 | During a create operation, the client's identity is recorded in the | |
7008 | Job object in an implementation-defined attribute. This information | |
7009 | can be used to verify a client's identity for subsequent operations | |
7010 | on that Job object in order to enforce any access control policy that | |
7011 | might be in effect. See section 8.3 below for more details. | |
7012 | ||
7013 | Since the security levels or the specific threats that any given IPP | |
7014 | system administrator may be concerned with cannot be anticipated, IPP | |
7015 | MUST be capable of operating with different security mechanisms and | |
7016 | security policies as required by the individual installation. | |
7017 | Security policies might vary from very strong, to very weak, to none | |
7018 | at all, and corresponding security mechanisms will be required. SSL3 | |
7019 | supports the type of negotiated levels of security required by most, | |
7020 | if not all, potential IPP environments. IPP environments that require | |
7021 | no security can elect to deploy IPP objects that do not utilize the | |
7022 | optional SSL3 security mechanisms. | |
7023 | ||
7024 | 8.1 Security Scenarios | |
7025 | ||
7026 | The following sections describe specific security attacks for IPP | |
7027 | environments. Where examples are provided they should be considered | |
7028 | illustrative of the environment and not an exhaustive set. Not all of | |
7029 | these environments will necessarily be addressed in initial | |
7030 | implementations of IPP. | |
7031 | ||
7032 | 8.1.1 Client and Server in the Same Security Domain | |
7033 | ||
7034 | This environment is typical of internal networks where traditional | |
7035 | office workers print the output of personal productivity applications | |
7036 | on shared work-group printers, or where batch applications print | |
7037 | their output on large production printers. Although the identity of | |
7038 | the user may be trusted in this environment, a user might want to | |
7039 | protect the content of a document against such attacks as | |
7040 | eavesdropping, replaying or tampering. | |
7041 | ||
7042 | 8.1.2 Client and Server in Different Security Domains | |
7043 | ||
7044 | Examples of this environment include printing a document created by | |
7045 | the client on a publicly available printer, such as at a commercial | |
7046 | print shop; or printing a document remotely on a business associate's | |
7047 | printer. This latter operation is functionally equivalent to sending | |
7048 | the document to the business associate as a facsimile. Printing | |
7049 | sensitive information on a Printer in a different security domain | |
7050 | requires strong security measures. In this environment authentication | |
7051 | of the printer is required as well as protection against unauthorized | |
7052 | use of print resources. Since the document crosses security domains, | |
7053 | ||
7054 | ||
7055 | ||
7056 | ||
7057 | ||
7058 | deBry, et al. Experimental [Page 126] | |
7059 | \f | |
7060 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7061 | ||
7062 | ||
7063 | protection against eavesdropping and document tampering are also | |
7064 | required. It will also be important in this environment to protect | |
7065 | Printers against "spamming" and malicious document content. | |
7066 | ||
7067 | 8.1.3 Print by Reference | |
7068 | ||
7069 | When the document is not stored on the client, printing can be done | |
7070 | by reference. That is, the print request can contain a reference, or | |
7071 | pointer, to the document instead of the actual document itself. | |
7072 | Standard methods currently do not exist for remote entities to | |
7073 | "assume" the credentials of a client for forwarding requests to a 3rd | |
7074 | party. It is anticipated that Print-By-Reference will be used to | |
7075 | access "public" documents and that sophisticated methods for | |
7076 | authenticating "proxies" will not be specified for version 1 of IPP. | |
7077 | ||
7078 | 8.2 URIs for SSL3 and non-SSL3 Access | |
7079 | ||
7080 | As described earlier, an IPP object can support SSL3 access, non-SSL3 | |
7081 | access, or both. The "printer-uri-supported" attribute contains the | |
7082 | Printer object's URI(s). Its companion attribute, "uri-security- | |
7083 | supported", identifies the security mechanism used for each URI | |
7084 | listed in the "printer-uri-supported" attribute. For each Printer | |
7085 | operation request, a client MUST supply only one URI in the | |
7086 | "printer-uri" operation attribute. In other words, even though the | |
7087 | Printer supports more than one URI, the client only interacts with | |
7088 | the Printer object using one if its URIs. This duality is not needed | |
7089 | for Job objects, since the Printer objects is the factory for Job | |
7090 | objects, and the Printer object will generate the correct URI for new | |
7091 | Job objects depending on the Printer object's security configuration. | |
7092 | ||
7093 | 8.3 The "requesting-user-name" (name(MAX)) Operation Attribute | |
7094 | ||
7095 | Each operation MUST specify the user who is performing the operation | |
7096 | in both of the following two ways: | |
7097 | ||
7098 | 1) via the REQUIRED "requesting-user-name" operation attribute that | |
7099 | a client SHOULD supply in all operations. The client MUST obtain | |
7100 | the value for this attribute from an environmental or network | |
7101 | login name for the user, rather than allowing the user to supply | |
7102 | any value. If the client does not supply a value for | |
7103 | "requesting-user-name", the printer MUST assume that the client | |
7104 | is supplying some anonymous name, such as "anonymous". | |
7105 | 2) via an authentication mechanism of the underlying transport | |
7106 | which may be configured to give no authentication information. | |
7107 | ||
7108 | ||
7109 | ||
7110 | ||
7111 | ||
7112 | ||
7113 | ||
7114 | deBry, et al. Experimental [Page 127] | |
7115 | \f | |
7116 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7117 | ||
7118 | ||
7119 | There are six cases to consider: | |
7120 | ||
7121 | a) the authentication mechanism gives no information, and the | |
7122 | client doesn't specify "requesting-user-name". | |
7123 | b) the authentication mechanism gives no information, but the | |
7124 | client specifies "requesting-user-name". | |
7125 | c) the authentication mechanism specifies a user which has no human | |
7126 | readable representation, and the client doesn't specify | |
7127 | "requesting-user-name". | |
7128 | d) the authentication mechanism specifies a user which has no human | |
7129 | readable representation, but the client specifies "requesting- | |
7130 | user-name". | |
7131 | e) the authentication mechanism specifies a user which has a human | |
7132 | readable representation. The Printer object ignores the | |
7133 | "requesting-user-name". | |
7134 | f) the authentication mechanism specifies a user who is trusted and | |
7135 | whose name means that the value of the "requesting-user-name", | |
7136 | which MUST be present, is treated as the authenticated name. | |
7137 | ||
7138 | Note: Case "f" is intended for a tightly coupled gateway and server | |
7139 | to work together so that the "user" name is able to be that of the | |
7140 | gateway client and not that of the gateway. Because most, if not | |
7141 | all, system vendors will initially implement IPP via a gateway into | |
7142 | their existing print system, this mechanism is necessary unless the | |
7143 | authentication mechanism allows a gateway (client) to act on behalf | |
7144 | of some other client. | |
7145 | ||
7146 | The user-name has two forms: | |
7147 | ||
7148 | - one that is human readable: it is held in the REQUIRED "job- | |
7149 | originating-user-name" Job Description attribute which is set | |
7150 | during the job creation operations. It is used for presentation | |
7151 | only, such as returning in queries or printing on start sheets | |
7152 | - one for authorization: it is held in an undefined (by IPP) Job | |
7153 | object attribute which is set by the job creation operation. It | |
7154 | is used to authorize other operations, such as Send-Document, | |
7155 | Send-URI, Cancel-Job, to determine the user when the "my-jobs" | |
7156 | attribute is specified with Get-Jobs, and to limit what | |
7157 | attributes and values to return with Get-Job-Attributes and Get- | |
7158 | Jobs. | |
7159 | ||
7160 | The human readable user name: | |
7161 | ||
7162 | - is the value of the "requesting-user-name" for cases b, d and f. | |
7163 | - comes from the authentication mechanism for case e | |
7164 | - is some anonymous name, such as "anonymous" for cases a and c. | |
7165 | ||
7166 | The user name used for authorization: | |
7167 | ||
7168 | ||
7169 | ||
7170 | deBry, et al. Experimental [Page 128] | |
7171 | \f | |
7172 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7173 | ||
7174 | ||
7175 | - is the value of the "requesting-user-name" for cases b and f. | |
7176 | - comes from the authentication mechanism for cases c, d and e | |
7177 | - is some anonymous name, such as "anonymous" for case a. | |
7178 | ||
7179 | The essence of these rules for resolving conflicting sources of | |
7180 | user-names is that a printer implementation is free to pick either | |
7181 | source as long as it achieves consistent results. That is, if a user | |
7182 | uses the same path for a series of requests, the requests MUST appear | |
7183 | to come from the same user from the standpoint of both the human- | |
7184 | readable user name and the user name for authorization. This rule | |
7185 | MUST continue to apply even if a request could be authenticated by | |
7186 | two or more mechanisms. It doesn't matter which of several | |
7187 | authentication mechanisms a Printer uses as long as it achieves | |
7188 | consistent results. If a client uses more than one authentication | |
7189 | mechanism, it is recommended that an administrator make all | |
7190 | credentials resolve to the same user and user-name as much as | |
7191 | possible. | |
7192 | ||
7193 | 8.4 Restricted Queries | |
7194 | ||
7195 | In many IPP operations, a client supplies a list of attributes to be | |
7196 | returned in the response. For security reasons, an IPP object may be | |
7197 | configured not to return all attributes (or all values) that a client | |
7198 | requests. The job attributes returned MAY depend on whether the | |
7199 | requesting user is the same as the user that submitted the job. The | |
7200 | IPP object MAY even return none of the requested attributes. In such | |
7201 | cases, the status returned is the same as if the object had returned | |
7202 | all requested attributes. The client cannot tell by such a response | |
7203 | whether the requested attribute was present or absent on the object. | |
7204 | ||
7205 | 8.5 Queries on jobs submitted using non-IPP protocols | |
7206 | ||
7207 | If the device that an IPP Printer is representing is able to accept | |
7208 | jobs using other job submission protocols in addition to IPP, it is | |
7209 | RECOMMENDED that such an implementation at least allow such "foreign" | |
7210 | jobs to be queried using Get-Jobs returning "job-id" and "job-uri" as | |
7211 | 'unknown'. Such an implementation NEED NOT support all of the same | |
7212 | IPP job attributes as for IPP jobs. The IPP object returns the ' | |
7213 | unknown' out-of-band value for any requested attribute of a foreign | |
7214 | job that is supported for IPP jobs, but not for foreign jobs. | |
7215 | ||
7216 | It is further RECOMMENDED, that the IPP Printer generate "job-id" and | |
7217 | "job-uri" values for such "foreign jobs", if possible, so that they | |
7218 | may be targets of other IPP operations, such as Get-Job-Attributes | |
7219 | and Cancel-Job. Such an implementation also needs to deal with the | |
7220 | problem of authentication of such foreign jobs. One approach would | |
7221 | be to treat all such foreign jobs as belonging to users other than | |
7222 | the user of the IPP client. Another approach would be for the | |
7223 | ||
7224 | ||
7225 | ||
7226 | deBry, et al. Experimental [Page 129] | |
7227 | \f | |
7228 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7229 | ||
7230 | ||
7231 | foreign job to belong to 'anonymous'. Only if the IPP client has | |
7232 | been authenticated as an operator or administrator of the IPP Printer | |
7233 | object, could the foreign jobs be queried by an IPP request. | |
7234 | Alternatively, if the security policy is to allow users to query | |
7235 | other users' jobs, then the foreign jobs would also be visible to an | |
7236 | end-user IPP client using Get-Jobs and Get-Job-Attributes. | |
7237 | ||
7238 | 8.6 IPP Security Application Profile for SSL3 | |
7239 | ||
7240 | The IPP application profile for SSL3 follows the "Secure Socket | |
7241 | Layer" requirement as documented in the SSL3 specification [SSL]. | |
7242 | For interoperability, the SSL3 cipher suites are: | |
7243 | ||
7244 | SSL_RSA_WITH_RC4_128_MD5 | |
7245 | SSL_RSA_WITH_3DES_EDE_CBC_SHA | |
7246 | SSL_RSA_WITH_DES_CBC_SHA | |
7247 | SSL_RSA_EXPORT_WITH_RC4_40_MD5 | |
7248 | SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 | |
7249 | SSL_RSA_WITH_NULL_MD5 | |
7250 | ||
7251 | Client implementations MUST NOT assume any other cipher suites are | |
7252 | supported by an IPP Printer object. | |
7253 | ||
7254 | If a conforming IPP object supports SSL3, it MUST implement and | |
7255 | support the cipher suites listed above and MAY support additional | |
7256 | cipher suites. | |
7257 | ||
7258 | A conforming IPP client SHOULD support SSL3 including the cipher | |
7259 | suites listed above. A conforming IPP client MAY support additional | |
7260 | cipher suites. | |
7261 | ||
7262 | It is possible that due to certain government export restrictions | |
7263 | some non-compliant versions of this extension could be deployed. | |
7264 | Implementations wishing to inter-operate with such non-compliant | |
7265 | versions MAY offer the SSL_RSA_EXPORT_WITH_RC4_40_MD5 and | |
7266 | SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 mechanisms. However, since 40 bit | |
7267 | ciphers are known to be vulnerable to attack by current technology, | |
7268 | any client which actives a 40 bit cipher MUST NOT indicate to the | |
7269 | user that the connection is completely secure from eavesdropping. | |
7270 | ||
7271 | ||
7272 | ||
7273 | ||
7274 | ||
7275 | ||
7276 | ||
7277 | ||
7278 | ||
7279 | ||
7280 | ||
7281 | ||
7282 | deBry, et al. Experimental [Page 130] | |
7283 | \f | |
7284 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7285 | ||
7286 | ||
7287 | 9. References | |
7288 | ||
7289 | [ASCII] Coded Character Set - 7-bit American Standard Code for | |
7290 | Information Interchange (ASCII), ANSI X3.4-1986. This | |
7291 | standard is the specification of the US-ASCII charset. | |
7292 | ||
7293 | [HTPP] J. Barnett, K. Carter, R. DeBry, "Initial Draft - | |
7294 | Hypertext Printing Protocol - HTPP/1.0", October 1996. | |
7295 | ftp://ftp.pwg.org/pub/pwg/ipp/historic/htpp/ | |
7296 | overview.ps.gz | |
7297 | ||
7298 | [IANA-CS] IANA Registry of Coded Character Sets: | |
7299 | ftp://ftp.isi.edu/in-notes/iana/assignments/character- | |
7300 | sets | |
7301 | ||
7302 | [IANA-MT] IANA Registry of Media Types: ftp://ftp.isi.edu/in- | |
7303 | notes/iana/assignments/media-types/ | |
7304 | ||
7305 | [ipp-iig] Hastings, T. and C. Manros, "Internet Printing | |
7306 | Protocol/1.0: Implementer's Guide", Work in Progress. | |
7307 | ||
7308 | [ISO10646-1] ISO/IEC 10646-1:1993, "Information technology -- | |
7309 | Universal Multiple-Octet Coded Character Set (UCS) - | |
7310 | Part 1: Architecture and Basic Multilingual Plane, | |
7311 | JTC1/SC2." | |
7312 | ||
7313 | [ISO8859-1] ISO/IEC 8859-1:1987, "Information technology -- 8-bit | |
7314 | One-Byte Coded Character Set - Part 1: Latin Alphabet Nr | |
7315 | 1", 1987, JTC1/SC2. | |
7316 | ||
7317 | [ISO10175] ISO/IEC 10175 Document Printing Application (DPA), June | |
7318 | 1996. | |
7319 | ||
7320 | [LDPA] T. Hastings, S. Isaacson, M. MacKay, C. Manros, D. Taylor, P. | |
7321 | Zehler, "LDPA - Lightweight Document Printing | |
7322 | Application", October 1996, | |
7323 | ftp://ftp.pwg.org/pub/pwg/ipp/historic/ldpa/ldpa8.pdf.gz | |
7324 | ||
7325 | [P1387.4] Kirk, M. (Editor), POSIX System Administration - Part 4: | |
7326 | Printing Interfaces, POSIX 1387.4 D8, 1994. | |
7327 | ||
7328 | [PSIS] Herriot, R. (editor), X/Open A Printing System | |
7329 | Interoperability Specification (PSIS), August 1995. | |
7330 | ||
7331 | [PWG] Printer Working Group, http://www.pwg.org. | |
7332 | ||
7333 | [RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND | |
7334 | SPECIFICATION", STD 13, RFC 1035, November 1987. | |
7335 | ||
7336 | ||
7337 | ||
7338 | deBry, et al. Experimental [Page 131] | |
7339 | \f | |
7340 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7341 | ||
7342 | ||
7343 | [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J. | |
7344 | Gyllenskog, "Printer MIB", RFC 1759, March 1995. | |
7345 | ||
7346 | [RFC1766] Alvestrand, H., "Tags for the Identification of | |
7347 | Languages", RFC 1766, March 1995. | |
7348 | ||
7349 | [RFC1179] McLaughlin, L. (Editor), "Line Printer Daemon Protocol", | |
7350 | RFC 1179, August 1990. | |
7351 | ||
7352 | [RFC1952] Deutsch, P., "GZIP file format specification version | |
7353 | 4.3", RFC 1952, May 1996. | |
7354 | ||
7355 | [RFC2045] Freed, N. and N. Borenstein, " Multipurpose Internet | |
7356 | Mail Extensions (MIME) Part One: Format of Internet | |
7357 | Message Bodies", RFC 2045, November 1996. | |
7358 | ||
7359 | [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |
7360 | Extensions (MIME) Part Two: Media Types", RFC 2046, | |
7361 | November 1996. | |
7362 | ||
7363 | [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose | |
7364 | Internet Mail Extension (MIME) Part Four: Registration | |
7365 | Procedures", RFC 2048, November 1996. | |
7366 | ||
7367 | [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. AND T. | |
7368 | Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", | |
7369 | RFC 2068, January 1997. | |
7370 | ||
7371 | [RFC2069] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., | |
7372 | Luotonen, A., Sink, E. and L. Stewart, "An Extension to | |
7373 | HTTP: Digest Access Authentication", RFC 2069, January | |
7374 | 1997. | |
7375 | ||
7376 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
7377 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
7378 | ||
7379 | [RFC2228] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC | |
7380 | 2228, October 1997. | |
7381 | ||
7382 | [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and | |
7383 | Languages" RFC 2277, January 1998. | |
7384 | ||
7385 | [RFC2278] Freed, N. and J. Postel: "IANA Charset Registration | |
7386 | Procedures", BCP 19, RFC 2278, January 1998. | |
7387 | ||
7388 | [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO | |
7389 | 10646", RFC 2279, January 1998. | |
7390 | ||
7391 | ||
7392 | ||
7393 | ||
7394 | deBry, et al. Experimental [Page 132] | |
7395 | \f | |
7396 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7397 | ||
7398 | ||
7399 | [RFC2316] Bellovin, S., "Report of the IAB Security Architecture | |
7400 | Workshop", RFC 2316, April 1998. | |
7401 | ||
7402 | [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform | |
7403 | Resource Identifiers (URI): Generic Syntax", RFC 2396, | |
7404 | August 1998. | |
7405 | ||
7406 | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |
7407 | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |
7408 | October 1998. | |
7409 | ||
7410 | [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner | |
7411 | "Internet Printing Protocol/1.0: Encoding and | |
7412 | Transport", RFC 2565, April 1999. | |
7413 | ||
7414 | [RFC2567] Wright, D., "Design Goals for an Internet Printing | |
7415 | Protocol", RFC 2567, April 1999. | |
7416 | ||
7417 | [RFC2568] Zilles, S., "Rationale for the Structure and Model and | |
7418 | Protocol for the Internet Printing Protocol", RFC 2568, | |
7419 | April 1999. | |
7420 | ||
7421 | [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, | |
7422 | "Mapping between LPD and IPP Protocols", RFC 2569, April | |
7423 | 1999. | |
7424 | ||
7425 | [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, | |
7426 | "Textual Conventions for SMIv2", STD 58, RFC 2579, April | |
7427 | 1999. | |
7428 | ||
7429 | [SSL] Netscape, The SSL Protocol, Version 3, (Text version | |
7430 | 3.02), November 1996. | |
7431 | ||
7432 | [SWP] P. Moore, B. Jahromi, S. Butler, "Simple Web Printing | |
7433 | SWP/1.0", May 7, 1997, | |
7434 | ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/swp9705.pdf | |
7435 | ||
7436 | ||
7437 | ||
7438 | ||
7439 | ||
7440 | ||
7441 | ||
7442 | ||
7443 | ||
7444 | ||
7445 | ||
7446 | ||
7447 | ||
7448 | ||
7449 | ||
7450 | deBry, et al. Experimental [Page 133] | |
7451 | \f | |
7452 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7453 | ||
7454 | ||
7455 | 10. Authors' Addresses | |
7456 | ||
7457 | Scott A. Isaacson (Editor) | |
7458 | Novell, Inc. | |
7459 | 122 E 1700 S | |
7460 | Provo, UT 84606 | |
7461 | ||
7462 | Phone: 801-861-7366 | |
7463 | Fax: 801-861-2517 | |
7464 | EMail: sisaacson@novell.com | |
7465 | ||
7466 | ||
7467 | Tom Hastings | |
7468 | Xerox Corporation | |
7469 | 737 Hawaii St. | |
7470 | El Segundo, CA 90245 | |
7471 | ||
7472 | Phone: 310-333-6413 | |
7473 | Fax: 310-333-5514 | |
7474 | EMail: hastings@cp10.es.xerox.com | |
7475 | ||
7476 | ||
7477 | Robert Herriot | |
7478 | Xerox Corporation | |
7479 | 3400 Hillview Ave., Bldg #1 | |
7480 | Palo Alto, CA 94304 | |
7481 | ||
7482 | Phone: 650-813-7696 | |
7483 | Fax: 650-813-6860 | |
7484 | EMail: robert.herriot@pahv.xerox.com | |
7485 | ||
7486 | ||
7487 | Roger deBry | |
7488 | Utah Valley State College | |
7489 | Orem, UT 84058 | |
7490 | ||
7491 | Phone: (801) 222-8000 | |
7492 | EMail: debryro@uvsc.edu | |
7493 | ||
7494 | ||
7495 | ||
7496 | ||
7497 | ||
7498 | ||
7499 | ||
7500 | ||
7501 | ||
7502 | ||
7503 | ||
7504 | ||
7505 | ||
7506 | deBry, et al. Experimental [Page 134] | |
7507 | \f | |
7508 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7509 | ||
7510 | ||
7511 | Patrick Powell | |
7512 | Astart Technologies | |
7513 | 9475 Chesapeake Dr., Suite D | |
7514 | San Diego, CA 95123 | |
7515 | ||
7516 | Phone: (619) 874-6543 | |
7517 | Fax: (619) 279-8424 | |
7518 | EMail: papowell@astart.com | |
7519 | ||
7520 | IPP Mailing List: ipp@pwg.org | |
7521 | IPP Mailing List Subscription: ipp-request@pwg.org | |
7522 | IPP Web Page: http://www.pwg.org/ipp/ | |
7523 | ||
7524 | Implementers of this specification are encouraged to join IPP Mailing | |
7525 | List in order to participate in any discussions of clarification | |
7526 | issues and review of registration proposals for additional attributes | |
7527 | and values. | |
7528 | ||
7529 | Other Participants: | |
7530 | ||
7531 | Chuck Adams - Tektronix | |
7532 | Jeff Barnett - IBM | |
7533 | Ron Bergman - Dataproducts Corp. | |
7534 | Sylvan Butler - HP | |
7535 | Keith Carter - IBM Corporation | |
7536 | Jeff Copeland - QMS | |
7537 | Andy Davidson - Tektronix | |
7538 | Mabry Dozier - QMS | |
7539 | Lee Farrell - Canon Information Systems | |
7540 | Steve Gebert - IBM | |
7541 | Babek Jahromi - Microsoft | |
7542 | David Kellerman - Northlake Software | |
7543 | Rick Landau - Digital | |
7544 | Greg LeClair - Epson | |
7545 | Harry Lewis - IBM | |
7546 | Pete Loya - HP | |
7547 | Ray Lutz - Cognisys | |
7548 | Mike MacKay - Novell, Inc. | |
7549 | Daniel Manchala - Xerox | |
7550 | Carl-Uno Manros - Xerox | |
7551 | Jay Martin - Underscore | |
7552 | Larry Masinter - Xerox | |
7553 | Stan McConnell - Xerox | |
7554 | Ira McDonald - High North Inc. | |
7555 | Paul Moore - Microsoft | |
7556 | Tetsuya Morita - Ricoh | |
7557 | Yuichi Niwa - Ricoh | |
7558 | Pat Nogay - IBM | |
7559 | ||
7560 | ||
7561 | ||
7562 | deBry, et al. Experimental [Page 135] | |
7563 | \f | |
7564 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7565 | ||
7566 | ||
7567 | Ron Norton - Printronics | |
7568 | Bob Pentecost - HP | |
7569 | Rob Rhoads - Intel | |
7570 | Xavier Riley - Xerox | |
7571 | David Roach - Unisys | |
7572 | Stuart Rowley - Kyocera | |
7573 | Hiroyuki Sato - Canon | |
7574 | Bob Setterbo - Adobe | |
7575 | Devon Taylor - Novell, Inc. | |
7576 | Mike Timperman - Lexmark | |
7577 | Randy Turner - Sharp | |
7578 | Atsushi Yuki - Kyocera | |
7579 | Rick Yardumian - Xerox | |
7580 | Lloyd Young - Lexmark | |
7581 | Bill Wagner - DPI | |
7582 | Jim Walker - DAZEL | |
7583 | Chris Wellens - Interworking Labs | |
7584 | Rob Whittle - Novell, Inc. | |
7585 | Don Wright - Lexmark | |
7586 | Peter Zehler - Xerox | |
7587 | Steve Zilles - Adobe | |
7588 | ||
7589 | 11. Formats for IPP Registration Proposals | |
7590 | ||
7591 | In order to propose an IPP extension for registration, the proposer | |
7592 | must submit an application to IANA by email to "iana@iana.org" or by | |
7593 | filling out the appropriate form on the IANA web pages | |
7594 | (http://www.iana.org). This section specifies the required | |
7595 | information and the formats for proposing registrations of extensions | |
7596 | to IPP as provided in Section 6 for: | |
7597 | ||
7598 | 1. type2 'keyword' attribute values | |
7599 | 2. type3 'keyword' attribute values | |
7600 | 3. type2 'enum' attribute values | |
7601 | 4. type3 'enum' attribute values | |
7602 | 5. attributes | |
7603 | 6. attribute syntaxes | |
7604 | 7. operations | |
7605 | 8. status codes | |
7606 | ||
7607 | 11.1 Type2 keyword attribute values registration | |
7608 | ||
7609 | Type of registration: type2 keyword attribute value | |
7610 | Name of attribute to which this keyword specification is to be added: | |
7611 | Proposed keyword name of this keyword value: | |
7612 | Specification of this keyword value (follow the style of IPP Model | |
7613 | Section 4.1.2.3): | |
7614 | Name of proposer: | |
7615 | ||
7616 | ||
7617 | ||
7618 | deBry, et al. Experimental [Page 136] | |
7619 | \f | |
7620 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7621 | ||
7622 | ||
7623 | Address of proposer: | |
7624 | Email address of proposer: | |
7625 | ||
7626 | Note: For type2 keywords, the Designated Expert will be the point of | |
7627 | contact for the approved registration specification, if any | |
7628 | maintenance of the registration specification is needed. | |
7629 | ||
7630 | 11.2 Type3 keyword attribute values registration | |
7631 | ||
7632 | Type of registration: type3 keyword attribute value | |
7633 | Name of attribute to which this keyword specification is to be added: | |
7634 | Proposed keyword name of this keyword value: | |
7635 | Specification of this keyword value (follow the style of IPP Model | |
7636 | Section 4.1.2.3): | |
7637 | Name of proposer: | |
7638 | Address of proposer: | |
7639 | Email address of proposer: | |
7640 | ||
7641 | Note: For type3 keywords, the proposer will be the point of contact | |
7642 | for the approved registration specification, if any maintenance of | |
7643 | the registration specification is needed. | |
7644 | ||
7645 | 11.3 Type2 enum attribute values registration | |
7646 | ||
7647 | Type of registration: type2 enum attribute value | |
7648 | Name of attribute to which this enum specification is to be added: | |
7649 | Keyword symbolic name of this enum value: | |
7650 | Numeric value (to be assigned by the IPP Designated Expert in | |
7651 | consultation with IANA): | |
7652 | Specification of this enum value (follow the style of IPP Model | |
7653 | Section 4.1.4): | |
7654 | Name of proposer: | |
7655 | Address of proposer: | |
7656 | Email address of proposer: | |
7657 | ||
7658 | Note: For type2 enums, the Designated Expert will be the point of | |
7659 | contact for the approved registration specification, if any | |
7660 | maintenance of the registration specification is needed. | |
7661 | ||
7662 | 11.4 Type3 enum attribute values registration | |
7663 | ||
7664 | Type of registration: type3 enum attribute value | |
7665 | Name of attribute to which this enum specification is to be added: | |
7666 | Keyword symbolic name of this enum value: | |
7667 | Numeric value (to be assigned by the IPP Designated Expert in | |
7668 | consultation with IANA): | |
7669 | Specification of this enum value (follow the style of IPP Model | |
7670 | Section 4.1.4): | |
7671 | ||
7672 | ||
7673 | ||
7674 | deBry, et al. Experimental [Page 137] | |
7675 | \f | |
7676 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7677 | ||
7678 | ||
7679 | Name of proposer: | |
7680 | Address of proposer: | |
7681 | Email address of proposer: | |
7682 | ||
7683 | Note: For type3 enums, the proposer will be the point of contact for | |
7684 | the approved registration specification, if any maintenance of the | |
7685 | registration specification is needed. | |
7686 | ||
7687 | 11.5 Attribute registration | |
7688 | ||
7689 | Type of registration: attribute | |
7690 | Proposed keyword name of this attribute: | |
7691 | Types of attribute (Operation, Job Template, Job Description, | |
7692 | Printer Description): | |
7693 | Operations to be used with if the attribute is an operation | |
7694 | attribute: | |
7695 | Object (Job, Printer, etc. if bound to an object): | |
7696 | Attribute syntax(es) (include 1setOf and range as in Section 4.2): | |
7697 | If attribute syntax is 'keyword' or 'enum', is it type2 or type3: | |
7698 | If this is a Printer attribute, MAY the value returned depend on | |
7699 | "document-format" (See Section 6.2): | |
7700 | If this is a Job Template attribute, how does its specification | |
7701 | depend on the value of the "multiple-document-handling" attribute: | |
7702 | Specification of this attribute (follow the style of IPP Model | |
7703 | Section 4.2): | |
7704 | Name of proposer: | |
7705 | Address of proposer: | |
7706 | Email address of proposer: | |
7707 | ||
7708 | Note: For attributes, the IPP Designated Expert will be the point of | |
7709 | contact for the approved registration specification, if any | |
7710 | maintenance of the registration specification is needed. | |
7711 | ||
7712 | 11.6 Attribute Syntax registration | |
7713 | ||
7714 | Type of registration: attribute syntax | |
7715 | Proposed name of this attribute syntax: | |
7716 | Type of attribute syntax (integer, octetString, character-string, | |
7717 | see [RFC2565]): | |
7718 | Numeric value (to be assigned by the IPP Designated Expert in | |
7719 | consultation with IANA): | |
7720 | Specification of this attribute (follow the style of IPP Model | |
7721 | Section 4.1): | |
7722 | Name of proposer: | |
7723 | Address of proposer: | |
7724 | Email address of proposer: | |
7725 | ||
7726 | ||
7727 | ||
7728 | ||
7729 | ||
7730 | deBry, et al. Experimental [Page 138] | |
7731 | \f | |
7732 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7733 | ||
7734 | ||
7735 | Note: For attribute syntaxes, the IPP Designated Expert will be the | |
7736 | point of contact for the approved registration specification, if any | |
7737 | maintenance of the registration specification is needed. | |
7738 | ||
7739 | 11.7 Operation registration | |
7740 | ||
7741 | Type of registration: operation | |
7742 | Proposed name of this operation: | |
7743 | Numeric operation-id value (to be assigned by the IPP Designated | |
7744 | Expert in consultation with IANA): | |
7745 | Object Target (Job, Printer, etc. that operation is upon): | |
7746 | Specification of this attribute (follow the style of IPP Model | |
7747 | Section 3): | |
7748 | Name of proposer: | |
7749 | Address of proposer: | |
7750 | Email address of proposer: | |
7751 | ||
7752 | Note: For operations, the IPP Designated Expert will be the point of | |
7753 | contact for the approved registration specification, if any | |
7754 | maintenance of the registration specification is needed. | |
7755 | ||
7756 | 11.8 Attribute Group registration | |
7757 | ||
7758 | Type of registration: attribute group | |
7759 | Proposed name of this attribute group: | |
7760 | Numeric tag according to [RFC2565] (to be assigned by the IPP | |
7761 | Designated Expert in consultation with IANA): | |
7762 | Operation requests and group number for each operation in which the | |
7763 | attribute group occurs: | |
7764 | Operation responses and group number for each operation in which the | |
7765 | attribute group occurs: | |
7766 | Specification of this attribute group (follow the style of IPP Model | |
7767 | Section 3): | |
7768 | Name of proposer: | |
7769 | Address of proposer: | |
7770 | Email address of proposer: | |
7771 | ||
7772 | Note: For attribute groups, the IPP Designated Expert will be the | |
7773 | point of contact for the approved registration specification, if any | |
7774 | maintenance of the registration specification is needed. | |
7775 | ||
7776 | 11.9 Status code registration | |
7777 | ||
7778 | Type of registration: status code | |
7779 | Keyword symbolic name of this status code value: | |
7780 | Numeric value (to be assigned by the IPP Designated Expert in | |
7781 | consultation with IANA): | |
7782 | Operations that this status code may be used with: | |
7783 | ||
7784 | ||
7785 | ||
7786 | deBry, et al. Experimental [Page 139] | |
7787 | \f | |
7788 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7789 | ||
7790 | ||
7791 | Specification of this status code (follow the style of IPP Model | |
7792 | Section 14 APPENDIX B: Status Codes and Suggested Status Code | |
7793 | Messages): | |
7794 | Name of proposer: | |
7795 | Address of proposer: | |
7796 | Email address of proposer: | |
7797 | ||
7798 | Note: For status codes, the Designated Expert will be the point of | |
7799 | contact for the approved registration specification, if any | |
7800 | maintenance of the registration specification is needed. | |
7801 | ||
7802 | ||
7803 | ||
7804 | ||
7805 | ||
7806 | ||
7807 | ||
7808 | ||
7809 | ||
7810 | ||
7811 | ||
7812 | ||
7813 | ||
7814 | ||
7815 | ||
7816 | ||
7817 | ||
7818 | ||
7819 | ||
7820 | ||
7821 | ||
7822 | ||
7823 | ||
7824 | ||
7825 | ||
7826 | ||
7827 | ||
7828 | ||
7829 | ||
7830 | ||
7831 | ||
7832 | ||
7833 | ||
7834 | ||
7835 | ||
7836 | ||
7837 | ||
7838 | ||
7839 | ||
7840 | ||
7841 | ||
7842 | deBry, et al. Experimental [Page 140] | |
7843 | \f | |
7844 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7845 | ||
7846 | ||
7847 | 12. APPENDIX A: Terminology | |
7848 | ||
7849 | This specification uses the terminology defined in this section. | |
7850 | ||
7851 | 12.1 Conformance Terminology | |
7852 | ||
7853 | The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", | |
7854 | "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be | |
7855 | interpreted as described in RFC 2119 [RFC2119]. | |
7856 | ||
7857 | 12.1.1 NEED NOT | |
7858 | ||
7859 | This term is not included in RFC 2119. The verb "NEED NOT" indicates | |
7860 | an action that the subject of the sentence does not have to implement | |
7861 | in order to claim conformance to the standard. The verb "NEED NOT" | |
7862 | is used instead of "MAY NOT" since "MAY NOT" sounds like a | |
7863 | prohibition. | |
7864 | ||
7865 | 12.2 Model Terminology | |
7866 | ||
7867 | 12.2.1 Keyword | |
7868 | ||
7869 | Keywords are used within this document as identifiers of semantic | |
7870 | entities within the abstract model (see section 4.1.2.3). Attribute | |
7871 | names, some attribute values, attribute syntaxes, and attribute group | |
7872 | names are represented as keywords. | |
7873 | ||
7874 | 12.2.2 Attributes | |
7875 | ||
7876 | An attribute is an item of information that is associated with an | |
7877 | instance of an IPP object. An attribute consists of an attribute | |
7878 | name and one or more attribute values. Each attribute has a specific | |
7879 | attribute syntax. All object attributes are defined in section 4 and | |
7880 | all operation attributes are defined in section 3. | |
7881 | ||
7882 | Job Template Attributes are described in section 4.2. The client | |
7883 | optionally supplies Job Template attributes in a create request | |
7884 | (operation requests that create Job objects). The Printer object has | |
7885 | associated attributes which define supported and default values for | |
7886 | the Printer. | |
7887 | ||
7888 | 12.2.2.1 Attribute Name | |
7889 | ||
7890 | Each attribute is uniquely identified in this document by its | |
7891 | attribute name. An attribute name is a keyword. The keyword | |
7892 | attribute name is given in the section header describing that | |
7893 | ||
7894 | ||
7895 | ||
7896 | ||
7897 | ||
7898 | deBry, et al. Experimental [Page 141] | |
7899 | \f | |
7900 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7901 | ||
7902 | ||
7903 | attribute. In running text in this document, attribute names are | |
7904 | indicated inside double quotation marks (") where the quotation marks | |
7905 | are not part of the keyword itself. | |
7906 | ||
7907 | 12.2.2.2 Attribute Group Name | |
7908 | ||
7909 | Related attributes are grouped into named groups. The name of the | |
7910 | group is a keyword. The group name may be used in place of naming | |
7911 | all the attributes in the group explicitly. Attribute groups are | |
7912 | defined in section 3. | |
7913 | ||
7914 | 12.2.2.3 Attribute Value | |
7915 | ||
7916 | Each attribute has one or more values. Attribute values are | |
7917 | represented in the syntax type specified for that attribute. In | |
7918 | running text in this document, attribute values are indicated inside | |
7919 | single quotation marks ('), whether their attribute syntax is | |
7920 | keyword, integer, text, etc. where the quotation marks are not part | |
7921 | of the value itself. | |
7922 | ||
7923 | 12.2.2.4 Attribute Syntax | |
7924 | ||
7925 | Each attribute is defined using an explicit syntax type. In this | |
7926 | document, each syntax type is defined as a keyword with specific | |
7927 | meaning. The Encoding and Transport document [RFC2565] indicates the | |
7928 | actual "on-the-wire" encoding rules for each syntax type. Attribute | |
7929 | syntax types are defined in section 4.1. | |
7930 | ||
7931 | 12.2.3 Supports | |
7932 | ||
7933 | By definition, a Printer object supports an attribute only if that | |
7934 | Printer object responds with the corresponding attribute populated | |
7935 | with some value(s) in a response to a query for that attribute. A | |
7936 | Printer object supports an attribute value if the value is one of the | |
7937 | Printer object's "supported values" attributes. The device behind a | |
7938 | Printer object may exhibit a behavior that corresponds to some IPP | |
7939 | attribute, but if the Printer object, when queried for that | |
7940 | attribute, doesn't respond with the attribute, then as far as IPP is | |
7941 | concerned, that implementation does not support that feature. If the | |
7942 | Printer object's "xxx-supported" attribute is not populated with a | |
7943 | particular value (even if that value is a legal value for that | |
7944 | attribute), then that Printer object does not support that particular | |
7945 | value. | |
7946 | ||
7947 | A conforming implementation MUST support all REQUIRED attributes. | |
7948 | However, even for REQUIRED attributes, conformance to IPP does not | |
7949 | mandate that all implementations support all possible values | |
7950 | representing all possible job processing behaviors and features. For | |
7951 | ||
7952 | ||
7953 | ||
7954 | deBry, et al. Experimental [Page 142] | |
7955 | \f | |
7956 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
7957 | ||
7958 | ||
7959 | example, if a given instance of a Printer supports only certain | |
7960 | document formats, then that Printer responds with the "document- | |
7961 | format-supported" attribute populated with a set of values, possibly | |
7962 | only one, taken from the entire set of possible values defined for | |
7963 | that attribute. This limited set of values represents the Printer's | |
7964 | set of supported document formats. Supporting an attribute and some | |
7965 | set of values for that attribute enables IPP end users to be aware of | |
7966 | and make use of those features associated with that attribute and | |
7967 | those values. If an implementation chooses to not support an | |
7968 | attribute or some specific value, then IPP end users would have no | |
7969 | ability to make use of that feature within the context of IPP itself. | |
7970 | However, due to existing practice and legacy systems which are not | |
7971 | IPP aware, there might be some other mechanism outside the scope of | |
7972 | IPP to control or request the "unsupported" feature (such as embedded | |
7973 | instructions within the document data itself). | |
7974 | ||
7975 | For example, consider the "finishings-supported" attribute. | |
7976 | ||
7977 | 1) If a Printer object is not physically capable of stapling, the | |
7978 | "finishings-supported" attribute MUST NOT be populated with the | |
7979 | value of 'staple'. | |
7980 | 2) A Printer object is physically capable of stapling, however an | |
7981 | implementation chooses not to support stapling in the IPP | |
7982 | "finishings" attribute. In this case, 'staple' MUST NOT be a | |
7983 | value in the "finishings-supported" Printer object attribute. | |
7984 | Without support for the value 'staple', an IPP end user would | |
7985 | have no means within the protocol itself to request that a Job | |
7986 | be stapled. However, an existing document data formatter might | |
7987 | be able to request that the document be stapled directly with an | |
7988 | embedded instruction within the document data. In this case, | |
7989 | the IPP implementation does not "support" stapling, however the | |
7990 | end user is still able to have some control over the stapling of | |
7991 | the completed job. | |
7992 | 3) A Printer object is physically capable of stapling, and an | |
7993 | implementation chooses to support stapling in the IPP | |
7994 | "finishings" attribute. In this case, 'staple' MUST be a value | |
7995 | in the "finishings-supported" Printer object attribute. Doing | |
7996 | so, would enable end users to be aware of and make use of the | |
7997 | stapling feature using IPP attributes. | |
7998 | ||
7999 | Even though support for Job Template attributes by a Printer object | |
8000 | is OPTIONAL, it is RECOMMENDED that if the device behind a Printer | |
8001 | object is capable of realizing any feature or function that | |
8002 | corresponds to an IPP attribute and some associated value, then that | |
8003 | implementation SHOULD support that IPP attribute and value. | |
8004 | ||
8005 | ||
8006 | ||
8007 | ||
8008 | ||
8009 | ||
8010 | deBry, et al. Experimental [Page 143] | |
8011 | \f | |
8012 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8013 | ||
8014 | ||
8015 | The set of values in any of the supported value attributes is set | |
8016 | (populated) by some administrative process or automatic sensing | |
8017 | mechanism that is outside the scope of IPP. For administrative | |
8018 | policy and control reasons, an administrator may choose to make only | |
8019 | a subset of possible values visible to the end user. In this case, | |
8020 | the real output device behind the IPP Printer abstraction may be | |
8021 | capable of a certain feature, however an administrator is specifying | |
8022 | that access to that feature not be exposed to the end user through | |
8023 | the IPP protocol. Also, since a Printer object may represent a | |
8024 | logical print device (not just a physical device) the actual process | |
8025 | for supporting a value is undefined and left up to the | |
8026 | implementation. However, if a Printer object supports a value, some | |
8027 | manual human action may be needed to realize the semantic action | |
8028 | associated with the value, but no end user action is required. | |
8029 | ||
8030 | For example, if one of the values in the "finishings-supported" | |
8031 | attribute is 'staple', the actual process might be an automatic | |
8032 | staple action by a physical device controlled by some command sent to | |
8033 | the device. Or, the actual process of stapling might be a manual | |
8034 | action by an operator at an operator attended Printer object. | |
8035 | ||
8036 | For another example of how supported attributes function, consider a | |
8037 | system administrator who desires to control all print jobs so that no | |
8038 | job sheets are printed in order to conserve paper. To force no job | |
8039 | sheets, the system administrator sets the only supported value for | |
8040 | the "job-sheets-supported" attribute to 'none'. In this case, if a | |
8041 | client requests anything except 'none', the create request is | |
8042 | rejected or the "job-sheets" value is ignored (depending on the value | |
8043 | of "ipp-attribute-fidelity"). To force the use of job start/end | |
8044 | sheets on all jobs, the administrator does not include the value ' | |
8045 | none' in the "job-sheets-supported" attribute. In this case, if a | |
8046 | client requests 'none', the create request is rejected or the "job- | |
8047 | sheets" value is ignored (again depending on the value of "ipp- | |
8048 | attribute-fidelity"). | |
8049 | ||
8050 | 12.2.4 print-stream page | |
8051 | ||
8052 | A "print-stream page" is a page according to the definition of pages | |
8053 | in the language used to express the document data. | |
8054 | ||
8055 | 12.2.5 impression | |
8056 | ||
8057 | An "impression" is the image (possibly many print-stream pages in | |
8058 | different configurations) imposed onto a single media page. | |
8059 | ||
8060 | ||
8061 | ||
8062 | ||
8063 | ||
8064 | ||
8065 | ||
8066 | deBry, et al. Experimental [Page 144] | |
8067 | \f | |
8068 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8069 | ||
8070 | ||
8071 | 13. APPENDIX B: Status Codes and Suggested Status Code Messages | |
8072 | ||
8073 | This section defines status code enum keywords and values that are | |
8074 | used to provide semantic information on the results of an operation | |
8075 | request. Each operation response MUST include a status code. The | |
8076 | response MAY also contain a status message that provides a short | |
8077 | textual description of the status. The status code is intended for | |
8078 | use by automata, and the status message is intended for the human end | |
8079 | user. Since the status message is an OPTIONAL component of the | |
8080 | operation response, an IPP application (i.e., a browser, GUI, print | |
8081 | driver or gateway) is NOT REQUIRED to examine or display the status | |
8082 | message, since it MAY not be returned to the application. | |
8083 | ||
8084 | The prefix of the status keyword defines the class of response as | |
8085 | follows: | |
8086 | ||
8087 | "informational" - Request received, continuing process | |
8088 | "successful" - The action was successfully received, understood, | |
8089 | and accepted | |
8090 | "redirection" - Further action must be taken in order to complete | |
8091 | the request | |
8092 | "client-error" - The request contains bad syntax or cannot be | |
8093 | fulfilled | |
8094 | "server-error" - The IPP object failed to fulfill an apparently | |
8095 | valid request | |
8096 | ||
8097 | As with type2 enums, IPP status codes are extensible. IPP clients | |
8098 | are NOT REQUIRED to understand the meaning of all registered status | |
8099 | codes, though such understanding is obviously desirable. However, | |
8100 | IPP clients MUST understand the class of any status code, as | |
8101 | indicated by the prefix, and treat any unrecognized response as being | |
8102 | equivalent to the first status code of that class, with the exception | |
8103 | that an unrecognized response MUST NOT be cached. For example, if an | |
8104 | unrecognized status code of "client-error-xxx-yyy" is received by the | |
8105 | client, it can safely assume that there was something wrong with its | |
8106 | request and treat the response as if it had received a "client- | |
8107 | error-bad-request" status code. In such cases, IPP applications | |
8108 | SHOULD present the OPTIONAL message (if present) to the end user | |
8109 | since the message is likely to contain human readable information | |
8110 | which will help to explain the unusual status. The name of the enum | |
8111 | is the suggested status message for US English. | |
8112 | ||
8113 | The status code values range from 0x0000 to 0x7FFF. The value ranges | |
8114 | for each status code class are as follows: | |
8115 | ||
8116 | "successful" - 0x0000 to 0x00FF | |
8117 | "informational" - 0x0100 to 0x01FF | |
8118 | "redirection" - 0x0200 to 0x02FF | |
8119 | ||
8120 | ||
8121 | ||
8122 | deBry, et al. Experimental [Page 145] | |
8123 | \f | |
8124 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8125 | ||
8126 | ||
8127 | "client-error" - 0x0400 to 0x04FF | |
8128 | "server-error" - 0x0500 to 0x05FF | |
8129 | ||
8130 | The top half (128 values) of each range (0x0n40 to 0x0nFF, for n = 0 | |
8131 | to 5) is reserved for private use within each status code class. | |
8132 | Values 0x0600 to 0x7FFF are reserved for future assignment and MUST | |
8133 | NOT be used. | |
8134 | ||
8135 | 13.1 Status Codes | |
8136 | ||
8137 | Each status code is described below. Section 13.1.5.9 contains a | |
8138 | table that indicates which status codes apply to which operations. | |
8139 | The Implementer's Guide [ipp-iig] describe the suggested steps for | |
8140 | processing IPP attributes for all operations, including returning | |
8141 | status codes. | |
8142 | ||
8143 | 13.1.1 Informational | |
8144 | ||
8145 | This class of status code indicates a provisional response and is to | |
8146 | be used for informational purposes only. | |
8147 | ||
8148 | There are no status codes defined in IPP/1.0 for this class of status | |
8149 | code. | |
8150 | ||
8151 | 13.1.2 Successful Status Codes | |
8152 | ||
8153 | This class of status code indicates that the client's request was | |
8154 | successfully received, understood, and accepted. | |
8155 | ||
8156 | 13.1.2.1 successful-ok (0x0000) | |
8157 | ||
8158 | The request has succeeded and no request attributes were substituted | |
8159 | or ignored. In the case of a response to a create request, the ' | |
8160 | successful-ok' status code indicates that the request was | |
8161 | successfully received and validated, and that the Job object has been | |
8162 | created; it does not indicate that the job has been processed. The | |
8163 | transition of the Job object into the 'completed' state is the only | |
8164 | indicator that the job has been printed. | |
8165 | ||
8166 | 13.1.2.2 successful-ok-ignored-or-substituted-attributes (0x0001) | |
8167 | ||
8168 | The request has succeeded, but some supplied (1) attributes were | |
8169 | ignored or (2) unsupported values were substituted with supported | |
8170 | values or were ignored in order to perform the operation without | |
8171 | rejecting it. Unsupported attributes, attribute syntaxes, or values | |
8172 | MUST be returned in the Unsupported Attributes group of the response | |
8173 | for all operations. There is an exception to this rule for the query | |
8174 | operations: Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes | |
8175 | ||
8176 | ||
8177 | ||
8178 | deBry, et al. Experimental [Page 146] | |
8179 | \f | |
8180 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8181 | ||
8182 | ||
8183 | for the "requested-attributes" operation attribute only. When the | |
8184 | supplied values of the "requested-attributes" operation attribute are | |
8185 | requesting attributes that are not supported, the IPP object MAY, but | |
8186 | is NOT REQUIRED to, return the "requested-attributes" attribute in | |
8187 | the Unsupported Attribute response group (with the unsupported values | |
8188 | only). See section 3.2.1.2. | |
8189 | ||
8190 | 13.1.2.3 successful-ok-conflicting-attributes (0x0002) | |
8191 | ||
8192 | The request has succeeded, but some supplied attribute values | |
8193 | conflicted with the values of other supplied attributes. These | |
8194 | conflicting values were either (1) substituted with (supported) | |
8195 | values or (2) the attributes were removed in order to process the job | |
8196 | without rejecting it. Attributes or values which conflict with other | |
8197 | attributes and have been substituted or ignored MUST be returned in | |
8198 | the Unsupported Attributes group of the response for all operations | |
8199 | as supplied by the client. See section 3.2.1.2. | |
8200 | ||
8201 | 13.1.3 Redirection Status Codes | |
8202 | ||
8203 | This class of status code indicates that further action needs to be | |
8204 | taken to fulfill the request. | |
8205 | ||
8206 | There are no status codes defined in IPP/1.0 for this class of status | |
8207 | code. | |
8208 | ||
8209 | 13.1.4 Client Error Status Codes | |
8210 | ||
8211 | This class of status code is intended for cases in which the client | |
8212 | seems to have erred. The IPP object SHOULD return a message | |
8213 | containing an explanation of the error situation and whether it is a | |
8214 | temporary or permanent condition. | |
8215 | ||
8216 | 13.1.4.1 client-error-bad-request (0x0400) | |
8217 | ||
8218 | The request could not be understood by the IPP object due to | |
8219 | malformed syntax (such as the value of a fixed length attribute whose | |
8220 | length does not match the prescribed length for that attribute - see | |
8221 | the Implementer's Guide [ipp-iig] ). The IPP application SHOULD NOT | |
8222 | repeat the request without modifications. | |
8223 | ||
8224 | 13.1.4.2 client-error-forbidden (0x0401) | |
8225 | ||
8226 | The IPP object understood the request, but is refusing to fulfill it. | |
8227 | Additional authentication information or authorization credentials | |
8228 | will not help and the request SHOULD NOT be repeated. This status | |
8229 | ||
8230 | ||
8231 | ||
8232 | ||
8233 | ||
8234 | deBry, et al. Experimental [Page 147] | |
8235 | \f | |
8236 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8237 | ||
8238 | ||
8239 | code is commonly used when the IPP object does not wish to reveal | |
8240 | exactly why the request has been refused or when no other response is | |
8241 | applicable. | |
8242 | ||
8243 | 13.1.4.3 client-error-not-authenticated (0x0402) | |
8244 | ||
8245 | The request requires user authentication. The IPP client may repeat | |
8246 | the request with suitable authentication information. If the request | |
8247 | already included authentication information, then this status code | |
8248 | indicates that authorization has been refused for those credentials. | |
8249 | If this response contains the same challenge as the prior response, | |
8250 | and the user agent has already attempted authentication at least | |
8251 | once, then the response message may contain relevant diagnostic | |
8252 | information. This status codes reveals more information than | |
8253 | "client-error-forbidden". | |
8254 | ||
8255 | 13.1.4.4 client-error-not-authorized (0x0403) | |
8256 | ||
8257 | The requester is not authorized to perform the request. Additional | |
8258 | authentication information or authorization credentials will not help | |
8259 | and the request SHOULD NOT be repeated. This status code is used | |
8260 | when the IPP object wishes to reveal that the authentication | |
8261 | information is understandable, however, the requester is explicitly | |
8262 | not authorized to perform the request. This status codes reveals | |
8263 | more information than "client-error-forbidden" and "client-error- | |
8264 | not-authenticated". | |
8265 | ||
8266 | 13.1.4.5 client-error-not-possible (0x0404) | |
8267 | ||
8268 | This status code is used when the request is for something that can | |
8269 | not happen. For example, there might be a request to cancel a job | |
8270 | that has already been canceled or aborted by the system. The IPP | |
8271 | client SHOULD NOT repeat the request. | |
8272 | ||
8273 | 13.1.4.6 client-error-timeout (0x0405) | |
8274 | ||
8275 | The client did not produce a request within the time that the IPP | |
8276 | object was prepared to wait. For example, a client issued a Create- | |
8277 | Job operation and then, after a long period of time, issued a Send- | |
8278 | Document operation and this error status code was returned in | |
8279 | response to the Send-Document request (see section 3.3.1). The IPP | |
8280 | object might have been forced to clean up resources that had been | |
8281 | held for the waiting additional Documents. The IPP object was forced | |
8282 | to close the Job since the client took too long. The client SHOULD | |
8283 | NOT repeat the request without modifications. | |
8284 | ||
8285 | ||
8286 | ||
8287 | ||
8288 | ||
8289 | ||
8290 | deBry, et al. Experimental [Page 148] | |
8291 | \f | |
8292 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8293 | ||
8294 | ||
8295 | 13.1.4.7 client-error-not-found (0x0406) | |
8296 | ||
8297 | The IPP object has not found anything matching the request URI. No | |
8298 | indication is given of whether the condition is temporary or | |
8299 | permanent. For example, a client with an old reference to a Job (a | |
8300 | URI) tries to cancel the Job, however in the mean time the Job might | |
8301 | have been completed and all record of it at the Printer has been | |
8302 | deleted. This status code, 'client-error-not-found' is returned | |
8303 | indicating that the referenced Job can not be found. This error | |
8304 | status code is also used when a client supplies a URI as a reference | |
8305 | to the document data in either a Print-URI or Send-URI operation, but | |
8306 | the document can not be found. | |
8307 | ||
8308 | In practice, an IPP application should avoid a not found situation by | |
8309 | first querying and presenting a list of valid Printer URIs and Job | |
8310 | URIs to the end-user. | |
8311 | ||
8312 | 13.1.4.8 client-error-gone (0x0407) | |
8313 | ||
8314 | The requested object is no longer available and no forwarding address | |
8315 | is known. This condition should be considered permanent. Clients | |
8316 | with link editing capabilities should delete references to the | |
8317 | request URI after user approval. If the IPP object does not know or | |
8318 | has no facility to determine, whether or not the condition is | |
8319 | permanent, the status code "client-error-not-found" should be used | |
8320 | instead. | |
8321 | ||
8322 | This response is primarily intended to assist the task of maintenance | |
8323 | by notifying the recipient that the resource is intentionally | |
8324 | unavailable and that the IPP object administrator desires that remote | |
8325 | links to that resource be removed. It is not necessary to mark all | |
8326 | permanently unavailable resources as "gone" or to keep the mark for | |
8327 | any length of time -- that is left to the discretion of the IPP | |
8328 | object administrator. | |
8329 | ||
8330 | 13.1.4.9 client-error-request-entity-too-large (0x0408) | |
8331 | ||
8332 | The IPP object is refusing to process a request because the request | |
8333 | entity is larger than the IPP object is willing or able to process. | |
8334 | An IPP Printer returns this status code when it limits the size of | |
8335 | print jobs and it receives a print job that exceeds that limit or | |
8336 | when the attributes are so many that their encoding causes the | |
8337 | request entity to exceed IPP object capacity. | |
8338 | ||
8339 | ||
8340 | ||
8341 | ||
8342 | ||
8343 | ||
8344 | ||
8345 | ||
8346 | deBry, et al. Experimental [Page 149] | |
8347 | \f | |
8348 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8349 | ||
8350 | ||
8351 | 13.1.4.10 client-error-request-value-too-long (0x0409) | |
8352 | ||
8353 | The IPP object is refusing to service the request because one or more | |
8354 | of the client-supplied attributes has a variable length value that is | |
8355 | longer than the maximum length specified for that attribute. The IPP | |
8356 | object might not have sufficient resources (memory, buffers, etc.) to | |
8357 | process (even temporarily), interpret, and/or ignore a value larger | |
8358 | than the maximum length. Another use of this error code is when the | |
8359 | IPP object supports the processing of a large value that is less than | |
8360 | the maximum length, but during the processing of the request as a | |
8361 | whole, the object may pass the value onto some other system component | |
8362 | which is not able to accept the large value. For more details, see | |
8363 | the Implementer's Guide [ipp-iig] . | |
8364 | ||
8365 | Note: For attribute values that are URIs, this rare condition is | |
8366 | only likely to occur when a client has improperly submitted a request | |
8367 | with long query information (e.g. an IPP application allows an end- | |
8368 | user to enter an invalid URI), when the client has descended into a | |
8369 | URI "black hole" of redirection (e.g., a redirected URI prefix that | |
8370 | points to a suffix of itself), or when the IPP object is under attack | |
8371 | by a client attempting to exploit security holes present in some IPP | |
8372 | objects using fixed-length buffers for reading or manipulating the | |
8373 | Request-URI. | |
8374 | ||
8375 | 13.1.4.11 client-error-document-format-not-supported (0x040A) | |
8376 | ||
8377 | The IPP object is refusing to service the request because the | |
8378 | document data is in a format, as specified in the "document-format" | |
8379 | operation attribute, that is not supported by the Printer object. | |
8380 | This error is returned independent of the client-supplied "ipp- | |
8381 | attribute-fidelity". The Printer object MUST return this status | |
8382 | code, even if there are other attributes that are not supported as | |
8383 | well, since this error is a bigger problem than with Job Template | |
8384 | attributes. | |
8385 | ||
8386 | 13.1.4.12 client-error-attributes-or-values-not-supported (0x040B) | |
8387 | ||
8388 | In a create request, if the Printer object does not support one or | |
8389 | more attributes, attribute syntaxes, or attribute values supplied in | |
8390 | the request and the client supplied the "ipp-attributes-fidelity" | |
8391 | operation attribute with the 'true' value, the Printer object MUST | |
8392 | return this status code. For example, if the request indicates ' | |
8393 | iso-a4' media, but that media type is not supported by the Printer | |
8394 | object. Or, if the client supplies an optional attribute and the | |
8395 | attribute itself is not even supported by the Printer. If the "ipp- | |
8396 | attribute-fidelity" attribute is 'false', the Printer MUST ignore or | |
8397 | substitute values for unsupported attributes and values rather than | |
8398 | reject the request and return this status code. | |
8399 | ||
8400 | ||
8401 | ||
8402 | deBry, et al. Experimental [Page 150] | |
8403 | \f | |
8404 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8405 | ||
8406 | ||
8407 | For any operation where a client requests attributes (such as a Get- | |
8408 | Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation), if | |
8409 | the IPP object does not support one or more of the requested | |
8410 | attributes, the IPP object simply ignores the unsupported requested | |
8411 | attributes and processes the request as if they had not been | |
8412 | supplied, rather than returning this status code. In this case, the | |
8413 | IPP object MUST return the 'successful-ok-ignored-or-substituted- | |
8414 | attributes' status code and MAY return the unsupported attributes as | |
8415 | values of the "requested-attributes" in the Unsupported Attributes | |
8416 | Group (see section 13.1.2.2). | |
8417 | ||
8418 | 13.1.4.13 client-error-uri-scheme-not-supported (0x040C) | |
8419 | ||
8420 | The type of the client supplied URI in a Print-URI or a Send-URI | |
8421 | operation is not supported. | |
8422 | ||
8423 | 13.1.4.14 client-error-charset-not-supported (0x040D) | |
8424 | ||
8425 | For any operation, if the IPP Printer does not support the charset | |
8426 | supplied by the client in the "attributes-charset" operation | |
8427 | attribute, the Printer MUST reject the operation and return this | |
8428 | status and any 'text' or 'name' attributes using the 'utf-8' charset | |
8429 | (see Section 3.1.4.1). | |
8430 | ||
8431 | 13.1.4.15 client-error-conflicting-attributes (0x040E) | |
8432 | ||
8433 | The request is rejected because some attribute values conflicted with | |
8434 | the values of other attributes which this specification does not | |
8435 | permit to be substituted or ignored. | |
8436 | ||
8437 | 13.1.5 Server Error Status Codes | |
8438 | ||
8439 | This class of status codes indicates cases in which the IPP object is | |
8440 | aware that it has erred or is incapable of performing the request. | |
8441 | The IPP object SHOULD include a message containing an explanation of | |
8442 | the error situation, and whether it is a temporary or permanent | |
8443 | condition. | |
8444 | ||
8445 | 13.1.5.1 server-error-internal-error (0x0500) | |
8446 | ||
8447 | The IPP object encountered an unexpected condition that prevented it | |
8448 | from fulfilling the request. This error status code differs from | |
8449 | "server-error-temporary-error" in that it implies a more permanent | |
8450 | type of internal error. It also differs from "server-error-device- | |
8451 | error" in that it implies an unexpected condition (unlike a paper-jam | |
8452 | or out-of-toner problem which is undesirable but expected). This | |
8453 | error status code indicates that probably some knowledgeable human | |
8454 | intervention is required. | |
8455 | ||
8456 | ||
8457 | ||
8458 | deBry, et al. Experimental [Page 151] | |
8459 | \f | |
8460 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8461 | ||
8462 | ||
8463 | 13.1.5.2 server-error-operation-not-supported (0x0501) | |
8464 | ||
8465 | The IPP object does not support the functionality required to fulfill | |
8466 | the request. This is the appropriate response when the IPP object | |
8467 | does not recognize an operation or is not capable of supporting it. | |
8468 | ||
8469 | 13.1.5.3 server-error-service-unavailable (0x0502) | |
8470 | ||
8471 | The IPP object is currently unable to handle the request due to a | |
8472 | temporary overloading or maintenance of the IPP object. The | |
8473 | implication is that this is a temporary condition which will be | |
8474 | alleviated after some delay. If known, the length of the delay may be | |
8475 | indicated in the message. If no delay is given, the IPP application | |
8476 | should handle the response as it would for a "server-error- | |
8477 | temporary-error" response. If the condition is more permanent, the | |
8478 | error status codes "client-error-gone" or "client-error-not-found" | |
8479 | could be used. | |
8480 | ||
8481 | 13.1.5.4 server-error-version-not-supported (0x0503) | |
8482 | ||
8483 | The IPP object does not support, or refuses to support, the IPP | |
8484 | protocol version that was used in the request message. The IPP | |
8485 | object is indicating that it is unable or unwilling to complete the | |
8486 | request using the same version as supplied in the request other than | |
8487 | with this error message. The response should contain a Message | |
8488 | describing why that version is not supported and what other versions | |
8489 | are supported by that IPP object. | |
8490 | ||
8491 | A conforming IPP/1.0 client MUST specify the valid version ('1.0') on | |
8492 | each request. A conforming IPP/1.0 object MUST NOT return this | |
8493 | status code to a conforming IPP/1.0 client. An IPP object MUST | |
8494 | return this status code to a non-conforming IPP client. The response | |
8495 | MUST identify in the "version-number" operation attribute the closest | |
8496 | version number that the IPP object does support. | |
8497 | ||
8498 | 13.1.5.5 server-error-device-error (0x0504) | |
8499 | ||
8500 | A printer error, such as a paper jam, occurs while the IPP object | |
8501 | processes a Print or Send operation. The response contains the true | |
8502 | Job Status (the values of the "job-state" and "job-state-reasons" | |
8503 | attributes). Additional information can be returned in the optional | |
8504 | "job-state-message" attribute value or in the OPTIONAL status message | |
8505 | that describes the error in more detail. This error status code is | |
8506 | only returned in situations where the Printer is unable to accept the | |
8507 | create request because of such a device error. For example, if the | |
8508 | Printer is unable to spool, and can only accept one job at a time, | |
8509 | the reason it might reject a create request is that the printer | |
8510 | currently has a paper jam. In many cases however, where the Printer | |
8511 | ||
8512 | ||
8513 | ||
8514 | deBry, et al. Experimental [Page 152] | |
8515 | \f | |
8516 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8517 | ||
8518 | ||
8519 | object can accept the request even though the Printer has some error | |
8520 | condition, the 'successful-ok' status code will be returned. In such | |
8521 | a case, the client would look at the returned Job Object Attributes | |
8522 | or later query the Printer to determine its state and state reasons. | |
8523 | ||
8524 | 13.1.5.6 server-error-temporary-error (0x0505) | |
8525 | ||
8526 | A temporary error such as a buffer full write error, a memory | |
8527 | overflow (i.e. the document data exceeds the memory of the Printer), | |
8528 | or a disk full condition, occurs while the IPP Printer processes an | |
8529 | operation. The client MAY try the unmodified request again at some | |
8530 | later point in time with an expectation that the temporary internal | |
8531 | error condition may have been cleared. Alternatively, as an | |
8532 | implementation option, a Printer object MAY delay the response until | |
8533 | the temporary condition is cleared so that no error is returned. | |
8534 | ||
8535 | 13.1.5.7 server-error-not-accepting-jobs (0x0506) | |
8536 | ||
8537 | A temporary error indicating that the Printer is not currently | |
8538 | accepting jobs, because the administrator has set the value of the | |
8539 | Printer's "printer-is-not-accepting-jobs" attribute to 'false' (by | |
8540 | means outside of IPP/1.0). | |
8541 | ||
8542 | 13.1.5.8 server-error-busy (0x0507) | |
8543 | ||
8544 | A temporary error indicating that the Printer is too busy processing | |
8545 | jobs and/or other requests. The client SHOULD try the unmodified | |
8546 | request again at some later point in time with an expectation that | |
8547 | the temporary busy condition will have been cleared. | |
8548 | ||
8549 | 13.1.5.9 server-error-job-canceled (0x0508) | |
8550 | ||
8551 | An error indicating that the job has been canceled by an operator or | |
8552 | the system while the client was transmitting the data to the IPP | |
8553 | Printer. If a job-id and job-uri had been created, then they are | |
8554 | returned in the Print-Job, Send-Document, or Send-URI response as | |
8555 | usual; otherwise, no job-id and job-uri are returned in the response. | |
8556 | ||
8557 | 13.2 Status Codes for IPP Operations | |
8558 | ||
8559 | PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document | |
8560 | SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and | |
8561 | Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job | |
8562 | ||
8563 | ||
8564 | ||
8565 | ||
8566 | ||
8567 | ||
8568 | ||
8569 | ||
8570 | deBry, et al. Experimental [Page 153] | |
8571 | \f | |
8572 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8573 | ||
8574 | ||
8575 | IPP Operations | |
8576 | IPP Status Keyword PJ PU CJ SD SU V GA GJ C | |
8577 | ------------------ -- -- -- -- -- - -- -- - | |
8578 | successful-ok x x x x x x x x x | |
8579 | successful-ok-ignored-or-substituted- x x x x x x x x x | |
8580 | attributes | |
8581 | successful-ok-conflicting-attributes x x x x x x x x x | |
8582 | client-error-bad-request x x x x x x x x x | |
8583 | client-error-forbidden x x x x x x x x x | |
8584 | client-error-not-authenticated x x x x x x x x x | |
8585 | client-error-not-authorized x x x x x x x x x | |
8586 | client-error-not-possible x x x x x x x x x | |
8587 | client-error-timeout x x | |
8588 | client-error-not-found x x x x x x x x x | |
8589 | client-error-gone x x x x x x x x x | |
8590 | client-error-request-entity-too-large x x x x x x x x x | |
8591 | client-error-request-value-too-long x x x x x x x x x | |
8592 | client-error-document-format-not- x x x x x x | |
8593 | supported | |
8594 | client-error-attributes-or-values-not- x x x x x x x x x | |
8595 | supported | |
8596 | client-error-uri-scheme-not-supported x x | |
8597 | client-error-charset-not-supported x x x x x x x x x | |
8598 | client-error-conflicting-attributes x x x x x x x x x | |
8599 | server-error-internal-error x x x x x x x x x | |
8600 | server-error-operation-not-supported x x x x | |
8601 | server-error-service-unavailable x x x x x x x x x | |
8602 | server-error-version-not-supported x x x x x x x x x | |
8603 | server-error-device-error x x x x x | |
8604 | server-error-temporary-error x x x x x | |
8605 | server-error-not-accepting-jobs x x x x | |
8606 | server-error-busy x x x x x x x x x | |
8607 | server-error-job-canceled x x | |
8608 | ||
8609 | ||
8610 | ||
8611 | ||
8612 | ||
8613 | ||
8614 | ||
8615 | ||
8616 | ||
8617 | ||
8618 | ||
8619 | ||
8620 | ||
8621 | ||
8622 | ||
8623 | ||
8624 | ||
8625 | ||
8626 | deBry, et al. Experimental [Page 154] | |
8627 | \f | |
8628 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8629 | ||
8630 | ||
8631 | 14. APPENDIX C: "media" keyword values | |
8632 | ||
8633 | Standard keyword values are taken from several sources. | |
8634 | ||
8635 | Standard values are defined (taken from DPA[ISO10175] and the Printer | |
8636 | MIB[RFC1759]): | |
8637 | ||
8638 | 'default': The default medium for the output device | |
8639 | 'iso-a4-white': Specifies the ISO A4 white medium | |
8640 | 'iso-a4-colored': Specifies the ISO A4 colored medium | |
8641 | 'iso-a4-transparent' Specifies the ISO A4 transparent medium | |
8642 | 'iso-a3-white': Specifies the ISO A3 white medium | |
8643 | 'iso-a3-colored': Specifies the ISO A3 colored medium | |
8644 | 'iso-a5-white': Specifies the ISO A5 white medium | |
8645 | 'iso-a5-colored': Specifies the ISO A5 colored medium | |
8646 | 'iso-b4-white': Specifies the ISO B4 white medium | |
8647 | 'iso-b4-colored': Specifies the ISO B4 colored medium | |
8648 | 'iso-b5-white': Specifies the ISO B5 white medium | |
8649 | 'iso-b5-colored': Specifies the ISO B5 colored medium | |
8650 | 'jis-b4-white': Specifies the JIS B4 white medium | |
8651 | 'jis-b4-colored': Specifies the JIS B4 colored medium | |
8652 | 'jis-b5-white': Specifies the JIS B5 white medium | |
8653 | 'jis-b5-colored': Specifies the JIS B5 colored medium | |
8654 | ||
8655 | The following standard values are defined for North American media: | |
8656 | ||
8657 | 'na-letter-white': Specifies the North American letter white medium | |
8658 | 'na-letter-colored': Specifies the North American letter colored | |
8659 | medium | |
8660 | 'na-letter-transparent': Specifies the North American letter | |
8661 | transparent medium | |
8662 | 'na-legal-white': Specifies the North American legal white medium | |
8663 | 'na-legal-colored': Specifies the North American legal colored | |
8664 | medium | |
8665 | ||
8666 | The following standard values are defined for envelopes: | |
8667 | ||
8668 | 'iso-b4-envelope': Specifies the ISO B4 envelope medium | |
8669 | 'iso-b5-envelope': Specifies the ISO B5 envelope medium | |
8670 | 'iso-c3-envelope': Specifies the ISO C3 envelope medium | |
8671 | 'iso-c4-envelope': Specifies the ISO C4 envelope medium | |
8672 | 'iso-c5-envelope': Specifies the ISO C5 envelope medium | |
8673 | 'iso-c6-envelope': Specifies the ISO C6 envelope medium | |
8674 | 'iso-designated-long-envelope': Specifies the ISO Designated Long | |
8675 | envelope medium | |
8676 | 'na-10x13-envelope': Specifies the North American 10x13 envelope | |
8677 | medium | |
8678 | ||
8679 | ||
8680 | ||
8681 | ||
8682 | deBry, et al. Experimental [Page 155] | |
8683 | \f | |
8684 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8685 | ||
8686 | ||
8687 | 'na-9x12-envelope': Specifies the North American 9x12 envelope | |
8688 | medium | |
8689 | 'monarch-envelope': Specifies the Monarch envelope | |
8690 | 'na-number-10-envelope': Specifies the North American number 10 | |
8691 | business envelope medium | |
8692 | 'na-7x9-envelope': Specifies the North American 7x9 inch envelope | |
8693 | 'na-9x11-envelope': Specifies the North American 9x11 inch envelope | |
8694 | 'na-10x14-envelope': Specifies the North American 10x14 inch | |
8695 | envelope | |
8696 | 'na-number-9-envelope': Specifies the North American number 9 | |
8697 | business envelope | |
8698 | 'na-6x9-envelope': Specifies the North American 6x9 inch envelope | |
8699 | 'na-10x15-envelope': Specifies the North American 10x15 inch | |
8700 | envelope | |
8701 | ||
8702 | The following standard values are defined for the less commonly used | |
8703 | media (white-only): | |
8704 | ||
8705 | 'executive-white': Specifies the white executive medium | |
8706 | 'folio-white': Specifies the folio white medium | |
8707 | 'invoice-white': Specifies the white invoice medium | |
8708 | 'ledger-white': Specifies the white ledger medium | |
8709 | 'quarto-white': Specified the white quarto medium | |
8710 | 'iso-a0-white': Specifies the ISO A0 white medium | |
8711 | 'iso-a1-white': Specifies the ISO A1 white medium | |
8712 | 'iso-a2-white': Specifies the ISO A2 white medium | |
8713 | 'iso-a6-white': Specifies the ISO A6 white medium | |
8714 | 'iso-a7-white': Specifies the ISO A7 white medium | |
8715 | 'iso-a8-white': Specifies the ISO A8 white medium | |
8716 | 'iso-a9-white': Specifies the ISO A9 white medium | |
8717 | 'iso-10-white': Specifies the ISO A10 white medium | |
8718 | 'iso-b0-white': Specifies the ISO B0 white medium | |
8719 | 'iso-b1-white': Specifies the ISO B1 white medium | |
8720 | 'iso-b2-white': Specifies the ISO B2 white medium | |
8721 | 'iso-b3-white': Specifies the ISO B3 white medium | |
8722 | 'iso-b6-white': Specifies the ISO B6 white medium | |
8723 | 'iso-b7-white': Specifies the ISO B7 white medium | |
8724 | 'iso-b8-white': Specifies the ISO B8 white medium | |
8725 | 'iso-b9-white': Specifies the ISO B9 white medium | |
8726 | 'iso-b10-white': Specifies the ISO B10 white medium | |
8727 | 'jis-b0-white': Specifies the JIS B0 white medium | |
8728 | 'jis-b1-white': Specifies the JIS B1 white medium | |
8729 | 'jis-b2-white': Specifies the JIS B2 white medium | |
8730 | 'jis-b3-white': Specifies the JIS B3 white medium | |
8731 | 'jis-b6-white': Specifies the JIS B6 white medium | |
8732 | 'jis-b7-white': Specifies the JIS B7 white medium | |
8733 | ||
8734 | ||
8735 | ||
8736 | ||
8737 | ||
8738 | deBry, et al. Experimental [Page 156] | |
8739 | \f | |
8740 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8741 | ||
8742 | ||
8743 | 'jis-b8-white': Specifies the JIS B8 white medium | |
8744 | 'jis-b9-white': Specifies the JIS B9 white medium | |
8745 | 'jis-b10-white': Specifies the JIS B10 white medium | |
8746 | ||
8747 | ||
8748 | The following standard values are defined for engineering media: | |
8749 | ||
8750 | 'a': Specifies the engineering A size medium | |
8751 | 'b': Specifies the engineering B size medium | |
8752 | 'c': Specifies the engineering C size medium | |
8753 | 'd': Specifies the engineering D size medium | |
8754 | 'e': Specifies the engineering E size medium | |
8755 | ||
8756 | ||
8757 | The following standard values are defined for input-trays (from ISO | |
8758 | DPA and the Printer MIB): | |
8759 | ||
8760 | 'top': The top input tray in the printer. | |
8761 | 'middle': The middle input tray in the printer. | |
8762 | 'bottom': The bottom input tray in the printer. | |
8763 | 'envelope': The envelope input tray in the printer. | |
8764 | 'manual': The manual feed input tray in the printer. | |
8765 | 'large-capacity': The large capacity input tray in the printer. | |
8766 | 'main': The main input tray | |
8767 | 'side': The side input tray | |
8768 | ||
8769 | ||
8770 | The following standard values are defined for media sizes (from ISO | |
8771 | DPA): | |
8772 | ||
8773 | 'iso-a0': Specifies the ISO A0 size: 841 mm by 1189 mm as defined | |
8774 | in ISO 216 | |
8775 | 'iso-a1': Specifies the ISO A1 size: 594 mm by 841 mm as defined in | |
8776 | ISO 216 | |
8777 | 'iso-a2': Specifies the ISO A2 size: 420 mm by 594 mm as defined in | |
8778 | ISO 216 | |
8779 | 'iso-a3': Specifies the ISO A3 size: 297 mm by 420 mm as defined in | |
8780 | ISO 216 | |
8781 | 'iso-a4': Specifies the ISO A4 size: 210 mm by 297 mm as defined in | |
8782 | ISO 216 | |
8783 | 'iso-a5': Specifies the ISO A5 size: 148 mm by 210 mm as defined in | |
8784 | ISO 216 | |
8785 | 'iso-a6': Specifies the ISO A6 size: 105 mm by 148 mm as defined in | |
8786 | ISO 216 | |
8787 | 'iso-a7': Specifies the ISO A7 size: 74 mm by 105 mm as defined in | |
8788 | ISO 216 | |
8789 | 'iso-a8': Specifies the ISO A8 size: 52 mm by 74 mm as defined in | |
8790 | ISO 216 | |
8791 | ||
8792 | ||
8793 | ||
8794 | deBry, et al. Experimental [Page 157] | |
8795 | \f | |
8796 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8797 | ||
8798 | ||
8799 | 'iso-a9': Specifies the ISO A9 size: 37 mm by 52 mm as defined in | |
8800 | ISO 216 | |
8801 | 'iso-a10': Specifies the ISO A10 size: 26 mm by 37 mm as defined in | |
8802 | ISO 216 | |
8803 | 'iso-b0': Specifies the ISO B0 size: 1000 mm by 1414 mm as defined | |
8804 | in ISO 216 | |
8805 | 'iso-b1': Specifies the ISO B1 size: 707 mm by 1000 mm as defined | |
8806 | in ISO 216 | |
8807 | 'iso-b2': Specifies the ISO B2 size: 500 mm by 707 mm as defined in | |
8808 | ISO 216 | |
8809 | 'iso-b3': Specifies the ISO B3 size: 353 mm by 500 mm as defined in | |
8810 | ISO 216 | |
8811 | 'iso-b4': Specifies the ISO B4 size: 250 mm by 353 mm as defined in | |
8812 | ISO 216 | |
8813 | 'iso-b5': Specifies the ISO B5 size: 176 mm by 250 mm as defined in | |
8814 | ISO 216 | |
8815 | 'iso-b6': Specifies the ISO B6 size: 125 mm by 176 mm as defined in | |
8816 | ISO 216 | |
8817 | 'iso-b7': Specifies the ISO B7 size: 88 mm by 125 mm as defined in | |
8818 | ISO 216 | |
8819 | 'iso-b8': Specifies the ISO B8 size: 62 mm by 88 mm as defined in | |
8820 | ISO 216 | |
8821 | 'iso-b9': Specifies the ISO B9 size: 44 mm by 62 mm as defined in | |
8822 | ISO 216 | |
8823 | 'iso-b10': Specifies the ISO B10 size: 31 mm by 44 mm as defined in | |
8824 | ISO 216 | |
8825 | 'na-letter': Specifies the North American letter size: 8.5 inches by | |
8826 | 11 inches | |
8827 | 'na-legal': Specifies the North American legal size: 8.5 inches by | |
8828 | 14 inches | |
8829 | 'executive': Specifies the executive size (7.25 X 10.5 in) | |
8830 | 'folio': Specifies the folio size (8.5 X 13 in) | |
8831 | 'invoice': Specifies the invoice size (5.5 X 8.5 in) | |
8832 | 'ledger': Specifies the ledger size (11 X 17 in) | |
8833 | 'quarto': Specifies the quarto size (8.5 X 10.83 in) | |
8834 | 'iso-c3': Specifies the ISO C3 size: 324 mm by 458 mm as defined in | |
8835 | ISO 269 | |
8836 | 'iso-c4': Specifies the ISO C4 size: 229 mm by 324 mm as defined in | |
8837 | ISO 269 | |
8838 | 'iso-c5': Specifies the ISO C5 size: 162 mm by 229 mm as defined in | |
8839 | ISO 269 | |
8840 | 'iso-c6': Specifies the ISO C6 size: 114 mm by 162 mm as defined in | |
8841 | ISO 269 | |
8842 | 'iso-designated-long': Specifies the ISO Designated Long size: 110 | |
8843 | mm by 220 mm as defined in ISO 269 | |
8844 | 'na-10x13-envelope': Specifies the North American 10x13 size: 10 | |
8845 | inches by 13 inches | |
8846 | ||
8847 | ||
8848 | ||
8849 | ||
8850 | deBry, et al. Experimental [Page 158] | |
8851 | \f | |
8852 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8853 | ||
8854 | ||
8855 | 'na-9x12-envelope': Specifies the North American 9x12 size: 9 | |
8856 | inches by 12 inches | |
8857 | 'na-number-10-envelope': Specifies the North American number 10 | |
8858 | business envelope size: 4.125 inches by 9.5 inches | |
8859 | 'na-7x9-envelope': Specifies the North American 7x9 inch envelope | |
8860 | size | |
8861 | 'na-9x11-envelope': Specifies the North American 9x11 inch envelope | |
8862 | size | |
8863 | 'na-10x14-envelope': Specifies the North American 10x14 inch | |
8864 | envelope size | |
8865 | 'na-number-9-envelope': Specifies the North American number 9 | |
8866 | business envelope size | |
8867 | 'na-6x9-envelope': Specifies the North American 6x9 envelope size | |
8868 | 'na-10x15-envelope': Specifies the North American 10x15 envelope | |
8869 | size | |
8870 | 'monarch-envelope': Specifies the Monarch envelope size (3.87 x 7.5 | |
8871 | in) | |
8872 | 'jis-b0': Specifies the JIS B0 size: 1030mm x 1456mm | |
8873 | 'jis-b1': Specifies the JIS B1 size: 728mm x 1030mm | |
8874 | 'jis-b2': Specifies the JIS B2 size: 515mm x 728mm | |
8875 | 'jis-b3': Specifies the JIS B3 size: 364mm x 515mm | |
8876 | 'jis-b4': Specifies the JIS B4 size: 257mm x 364mm | |
8877 | 'jis-b5': Specifies the JIS B5 size: 182mm x 257mm | |
8878 | 'jis-b6': Specifies the JIS B6 size: 128mm x 182mm | |
8879 | 'jis-b7': Specifies the JIS B7 size: 91mm x 128mm | |
8880 | 'jis-b8': Specifies the JIS B8 size: 64mm x 91mm | |
8881 | 'jis-b9': Specifies the JIS B9 size: 45mm x 64mm | |
8882 | 'jis-b10': Specifies the JIS B10 size: 32mm x 45mm | |
8883 | ||
8884 | ||
8885 | ||
8886 | ||
8887 | ||
8888 | ||
8889 | ||
8890 | ||
8891 | ||
8892 | ||
8893 | ||
8894 | ||
8895 | ||
8896 | ||
8897 | ||
8898 | ||
8899 | ||
8900 | ||
8901 | ||
8902 | ||
8903 | ||
8904 | ||
8905 | ||
8906 | deBry, et al. Experimental [Page 159] | |
8907 | \f | |
8908 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8909 | ||
8910 | ||
8911 | 15. APPENDIX D: Processing IPP Attributes | |
8912 | ||
8913 | When submitting a print job to a Printer object, the IPP model allows | |
8914 | a client to supply operation and Job Template attributes along with | |
8915 | the document data. These Job Template attributes in the create | |
8916 | request affect the rendering, production and finishing of the | |
8917 | documents in the job. Similar types of instructions may also be | |
8918 | contained in the document to be printed, that is, embedded within the | |
8919 | print data itself. In addition, the Printer has a set of attributes | |
8920 | that describe what rendering and finishing options which are | |
8921 | supported by that Printer. This model, which allows for flexibility | |
8922 | and power, also introduces the potential that at job submission time, | |
8923 | these client-supplied attributes may conflict with either: | |
8924 | ||
8925 | - what the implementation is capable of realizing (i.e., what the | |
8926 | Printer supports), as well as | |
8927 | - the instructions embedded within the print data itself. | |
8928 | ||
8929 | The following sections describe how these two types of conflicts are | |
8930 | handled in the IPP model. | |
8931 | ||
8932 | 15.1 Fidelity | |
8933 | ||
8934 | If there is a conflict between what the client requests and what a | |
8935 | Printer object supports, the client may request one of two possible | |
8936 | conflict handling mechanisms: | |
8937 | ||
8938 | 1) either reject the job since the job can not be processed exactly | |
8939 | as specified, or | |
8940 | 2) allow the Printer to make any changes necessary to proceed with | |
8941 | processing the Job the best it can. | |
8942 | ||
8943 | In the first case the client is indicating to the Printer object: | |
8944 | "Print the job exactly as specified with no exceptions, and if that | |
8945 | can't be done, don't even bother printing the job at all." In the | |
8946 | second case, the client is indicating to the Printer object: "It is | |
8947 | more important to make sure the job is printed rather than be | |
8948 | processed exactly as specified; just make sure the job is printed | |
8949 | even if client supplied attributes need to be changed or ignored." | |
8950 | ||
8951 | The IPP model accounts for this situation by introducing an "ipp- | |
8952 | attribute-fidelity" attribute. | |
8953 | ||
8954 | In a create request, "ipp-attribute-fidelity" is a boolean operation | |
8955 | attribute that is OPTIONALLY supplied by the client. The value ' | |
8956 | true' indicates that total fidelity to client supplied Job Template | |
8957 | attributes and values is required. The client is requesting that the | |
8958 | Job be printed exactly as specified, and if that is not possible then | |
8959 | ||
8960 | ||
8961 | ||
8962 | deBry, et al. Experimental [Page 160] | |
8963 | \f | |
8964 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
8965 | ||
8966 | ||
8967 | the job MUST be rejected rather than processed incorrectly. The | |
8968 | value 'false' indicates that a reasonable attempt to print the Job is | |
8969 | acceptable. If a Printer does not support some of the client | |
8970 | supplied Job Template attributes or values, the Printer MUST ignore | |
8971 | them or substitute any supported value for unsupported values, | |
8972 | respectively. The Printer may choose to substitute the default value | |
8973 | associated with that attribute, or use some other supported value | |
8974 | that is similar to the unsupported requested value. For example, if | |
8975 | a client supplies a "media" value of 'na-letter', the Printer may | |
8976 | choose to substitute 'iso-a4' rather than a default value of ' | |
8977 | envelope'. If the client does not supply the "ipp-attribute-fidelity" | |
8978 | attribute, the Printer assumes a value of 'false'. | |
8979 | ||
8980 | Each Printer implementation MUST support both types of "fidelity" | |
8981 | printing (that is whether the client supplies a value of 'true' or ' | |
8982 | false'): | |
8983 | ||
8984 | - If the client supplies 'false' or does not supply the attribute, | |
8985 | the Printer object MUST always accept the request by ignoring | |
8986 | unsupported Job Template attributes and by substituting | |
8987 | unsupported values of supported Job Template attributes with | |
8988 | supported values. | |
8989 | - If the client supplies 'true', the Printer object MUST reject the | |
8990 | request if the client supplies unsupported Job Template | |
8991 | attributes. | |
8992 | ||
8993 | Since a client can always query a Printer to find out exactly what is | |
8994 | and is not supported, "ipp-attribute-fidelity" set to 'false' is | |
8995 | useful when: | |
8996 | ||
8997 | 1) The End-User uses a command line interface to request attributes | |
8998 | that might not be supported. | |
8999 | 2) In a GUI context, if the End User expects the job might be moved | |
9000 | to another printer and prefers a sub-optimal result to nothing | |
9001 | at all. | |
9002 | 3) The End User just wants something reasonable in lieu of nothing | |
9003 | at all. | |
9004 | ||
9005 | 15.2 Page Description Language (PDL) Override | |
9006 | ||
9007 | If there is a conflict between the value of an IPP Job Template | |
9008 | attribute and a corresponding instruction in the document data, the | |
9009 | value of the IPP attribute SHOULD take precedence over the document | |
9010 | instruction. Consider the case where a previously formatted file of | |
9011 | document data is sent to an IPP Printer. In this case, if the client | |
9012 | supplies any attributes at job submission time, the client desires | |
9013 | that those attributes override the embedded instructions. Consider | |
9014 | the case were a previously formatted document has embedded in it | |
9015 | ||
9016 | ||
9017 | ||
9018 | deBry, et al. Experimental [Page 161] | |
9019 | \f | |
9020 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9021 | ||
9022 | ||
9023 | commands to load 'iso-a4' media. However, the document is passed to | |
9024 | an end user that only has access to a printer with 'na-letter' media | |
9025 | loaded. That end user most likely wants to submit that document to | |
9026 | an IPP Printer with the "media" Job Template attribute set to 'na- | |
9027 | letter'. The job submission attribute should take precedence over | |
9028 | the embedded PDL instruction. However, until companies that supply | |
9029 | document data interpreters allow a way for external IPP attributes to | |
9030 | take precedence over embedded job production instructions, a Printer | |
9031 | might not be able to support the semantics that IPP attributes | |
9032 | override the embedded instructions. | |
9033 | ||
9034 | The IPP model accounts for this situation by introducing a "pdl- | |
9035 | override-supported" attribute that describes the Printer objects | |
9036 | capabilities to override instructions embedded in the PDL data | |
9037 | stream. The value of the "pdl-override-supported" attribute is | |
9038 | configured by means outside IPP/1.0. | |
9039 | ||
9040 | This REQUIRED Printer attribute takes on the following values: | |
9041 | ||
9042 | - 'attempted': This value indicates that the Printer object | |
9043 | attempts to make the IPP attribute values take precedence over | |
9044 | embedded instructions in the document data, however there is no | |
9045 | guarantee. | |
9046 | - 'not-attempted': This value indicates that the Printer object | |
9047 | makes no attempt to make the IPP attribute values take precedence | |
9048 | over embedded instructions in the document data. | |
9049 | ||
9050 | At job processing time, an implementation that supports the value of | |
9051 | 'attempted' might do one of several different actions: | |
9052 | ||
9053 | 1) Generate an output device specific command sequence to realize | |
9054 | the feature represented by the IPP attribute value. | |
9055 | 2) Parse the document data itself and replace the conflicting | |
9056 | embedded instruction with a new embedded instruction that | |
9057 | matches the intent of the IPP attribute value. | |
9058 | 3) Indicate to the Printer that external supplied attributes take | |
9059 | precedence over embedded instructions and then pass the external | |
9060 | IPP attribute values to the document data interpreter. | |
9061 | 4) Anything else that allows for the semantics that IPP attributes | |
9062 | override embedded document data instructions. | |
9063 | ||
9064 | Since 'attempted' does not offer any type of guarantee, even though a | |
9065 | given Printer object might not do a very "good" job of attempting to | |
9066 | ensure that IPP attributes take a higher precedence over instructions | |
9067 | embedded in the document data, it would still be a conforming | |
9068 | implementation. | |
9069 | ||
9070 | ||
9071 | ||
9072 | ||
9073 | ||
9074 | deBry, et al. Experimental [Page 162] | |
9075 | \f | |
9076 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9077 | ||
9078 | ||
9079 | At job processing time, an implementation that supports the value of | |
9080 | 'not-attempted' might do one of the following actions: | |
9081 | ||
9082 | 1) Simply pre-pend the document data with the PDL instruction that | |
9083 | corresponds to the client-supplied PDL attribute, such that if | |
9084 | the document data also has the same PDL instruction, it will | |
9085 | override what the Printer object pre-pended. In other words, | |
9086 | this implementation is using the same implementation semantics | |
9087 | for the client-supplied IPP attributes as for the Printer object | |
9088 | defaults. | |
9089 | 2) Parse the document data and replace the conflicting embedded | |
9090 | instruction with a new embedded instruction that approximates, | |
9091 | but does not match, the semantic intent of the IPP attribute | |
9092 | value. | |
9093 | ||
9094 | Note: The "ipp-attribute-fidelity" attribute applies to the | |
9095 | Printer's ability to either accept or reject other unsupported Job | |
9096 | Template attributes. In other words, if "ipp-attribute-fidelity" is | |
9097 | set to 'true', a Job is accepted if and only if the client supplied | |
9098 | Job Template attributes and values are supported by the Printer. | |
9099 | Whether these attributes actually affect the processing of the Job | |
9100 | when the document data contains embedded instructions depends on the | |
9101 | ability of the Printer to override the instructions embedded in the | |
9102 | document data with the semantics of the IPP attributes. If the | |
9103 | document data attributes can be overridden ("pdl-override-supported" | |
9104 | set to 'attempted'), the Printer makes an attempt to use the IPP | |
9105 | attributes when processing the Job. If the document data attributes | |
9106 | can not be overridden ("pdl-override-supported" set to 'not- | |
9107 | attempted'), the Printer makes no attempt to override the embedded | |
9108 | document data instructions with the IPP attributes when processing | |
9109 | the Job, and hence, the IPP attributes may fail to affect the Job | |
9110 | processing and output when the corresponding instruction is embedded | |
9111 | in the document data. | |
9112 | ||
9113 | 15.3 Using Job Template Attributes During Document Processing. | |
9114 | ||
9115 | The Printer object uses some of the Job object's Job Template | |
9116 | attributes during the processing of the document data associated with | |
9117 | that job. These include, but are not limited to, "orientation", | |
9118 | "number-up", "sides", "media", and "copies". The processing of each | |
9119 | document in a Job Object MUST follow the steps below. These steps are | |
9120 | intended only to identify when and how attributes are to be used in | |
9121 | processing document data and any alternative steps that accomplishes | |
9122 | the same effect can be used to implement this specification. | |
9123 | ||
9124 | 1. Using the client supplied "document-format" attribute or some | |
9125 | form of document format detection algorithm (if the value of | |
9126 | "document- format" is not specific enough), determine whether or | |
9127 | ||
9128 | ||
9129 | ||
9130 | deBry, et al. Experimental [Page 163] | |
9131 | \f | |
9132 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9133 | ||
9134 | ||
9135 | not the document data has already been formatted for printing. | |
9136 | If the document data has been formatted, then go to step 2. | |
9137 | Otherwise, the document data MUST be formatted. The formatting | |
9138 | detection algorithm is implementation defined and is not | |
9139 | specified by this specification. The formatting of the document | |
9140 | data uses the "orientation-requested" attribute to determine how | |
9141 | the formatted print data should be placed on a print-stream | |
9142 | page, see section 4.2.10 for the details. | |
9143 | ||
9144 | 2. The document data is in the form of a print-stream in a known | |
9145 | media type. The "page-ranges" attribute is used to select, as | |
9146 | specified in section 4.2.7, a sub-sequence of the pages in the | |
9147 | print-stream that are to be processed and images. | |
9148 | ||
9149 | 3. The input to this step is a sequence of print-stream pages. This | |
9150 | step is controlled by the "number-up" attribute. If the value of | |
9151 | "number-up" is N, then during the processing of the print-stream | |
9152 | pages, each N print-stream pages are positioned, as specified in | |
9153 | section 4.2.9, to create a single impression. If a given | |
9154 | document does not have N more print-stream pages, then the | |
9155 | completion of the impression is controlled by the "multiple- | |
9156 | document-handling" attribute as described in section 4.2.4; when | |
9157 | the value of this attribute is 'single-document' or 'single- | |
9158 | document-new-sheet', the print-stream pages of document data | |
9159 | from subsequent documents is used to complete the impression. | |
9160 | ||
9161 | The size(scaling), position(translation) and rotation of the | |
9162 | print-stream pages on the impression is implementation defined. | |
9163 | Note that during this process the print-stream pages may be | |
9164 | rendered to a form suitable for placing on the impression; this | |
9165 | rendering is controlled by the values of the "printer- | |
9166 | resolution" and "print- quality" attributes as described in | |
9167 | sections 4.2.12 and 4.2.13. In the case N=1, the impression is | |
9168 | nearly the same as the print-stream page; the differences would | |
9169 | only be in the size, position and rotation of the print-stream | |
9170 | page and/or any decoration, such as a frame to the page, that is | |
9171 | added by the implementation. | |
9172 | ||
9173 | 4. The collection of impressions is placed, in sequence, onto sides | |
9174 | of the media sheets. This placement is controlled by the "sides" | |
9175 | attribute and the orientation of the print-stream page, as | |
9176 | described in section 4.2.8. The orientation of the print-stream | |
9177 | pages affects the orientation of the impression; for example, if | |
9178 | "number-up" equals 2, then, typically, two portrait print-stream | |
9179 | pages become one landscape impression. Note that the placement | |
9180 | of impressions onto media sheets is also controlled by the | |
9181 | "multiple-document-handling" attribute as described in section | |
9182 | 4.2.4. | |
9183 | ||
9184 | ||
9185 | ||
9186 | deBry, et al. Experimental [Page 164] | |
9187 | \f | |
9188 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9189 | ||
9190 | ||
9191 | 5. The "copies" and "multiple-document-handling" attributes are | |
9192 | used to determine how many copies of each media instance are | |
9193 | created and in what order. See sections 4.2.5 and 4.2.4 for the | |
9194 | details. | |
9195 | ||
9196 | 6. When the correct number of copies are created, the media | |
9197 | instances are finished according to the values of the | |
9198 | "finishings" attribute as described in 4.2.6. Note that | |
9199 | sometimes finishing operations may require manual intervention | |
9200 | to perform the finishing operations on the copies, especially | |
9201 | uncollated copies. This specification allows any or all of the | |
9202 | processing steps to be performed automatically or manually at | |
9203 | the discretion of the Printer object. | |
9204 | ||
9205 | ||
9206 | ||
9207 | ||
9208 | ||
9209 | ||
9210 | ||
9211 | ||
9212 | ||
9213 | ||
9214 | ||
9215 | ||
9216 | ||
9217 | ||
9218 | ||
9219 | ||
9220 | ||
9221 | ||
9222 | ||
9223 | ||
9224 | ||
9225 | ||
9226 | ||
9227 | ||
9228 | ||
9229 | ||
9230 | ||
9231 | ||
9232 | ||
9233 | ||
9234 | ||
9235 | ||
9236 | ||
9237 | ||
9238 | ||
9239 | ||
9240 | ||
9241 | ||
9242 | deBry, et al. Experimental [Page 165] | |
9243 | \f | |
9244 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9245 | ||
9246 | ||
9247 | 16. APPENDIX E: Generic Directory Schema | |
9248 | ||
9249 | This section defines a generic schema for an entry in a directory | |
9250 | service. A directory service is a means by which service users can | |
9251 | locate service providers. In IPP environments, this means that IPP | |
9252 | Printers can be registered (either automatically or with the help of | |
9253 | an administrator) as entries of type printer in the directory using | |
9254 | an implementation specific mechanism such as entry attributes, entry | |
9255 | type fields, specific branches, etc. IPP clients can search or | |
9256 | browse for entries of type printer. Clients use the directory | |
9257 | service to find entries based on naming, organizational contexts, or | |
9258 | filtered searches on attribute values of entries. For example, a | |
9259 | client can find all printers in the "Local Department" context. | |
9260 | Authentication and authorization are also often part of a directory | |
9261 | service so that an administrator can place limits on end users so | |
9262 | that they are only allowed to find entries to which they have certain | |
9263 | access rights. IPP itself does not require any specific directory | |
9264 | service protocol or provider. | |
9265 | ||
9266 | Note: Some directory implementations allow for the notion of | |
9267 | "aliasing". That is, one directory entry object can appear as | |
9268 | multiple directory entry object with different names for each object. | |
9269 | In each case, each alias refers to the same directory entry object | |
9270 | which refers to a single IPP Printer object. | |
9271 | ||
9272 | The generic schema is a subset of IPP Printer Job Template and | |
9273 | Printer Description attributes (sections 4.2 and 4.4). These | |
9274 | attributes are identified as either RECOMMENDED or OPTIONAL for the | |
9275 | directory entry itself. This conformance labeling is NOT the same | |
9276 | conformance labeling applied to the attributes of IPP Printers | |
9277 | objects. The conformance labeling in this Appendix is intended to | |
9278 | apply to directory templates and to IPP Printer implementations that | |
9279 | subscribe by adding one or more entries to a directory. RECOMMENDED | |
9280 | attributes SHOULD be associated with each directory entry. OPTIONAL | |
9281 | attributes MAY be associated with the directory entry (if known or | |
9282 | supported). In addition, all directory entry attributes SHOULD | |
9283 | reflect the current attribute values for the corresponding Printer | |
9284 | object. | |
9285 | ||
9286 | The names of attributes in directory schema and entries SHOULD be the | |
9287 | same as the IPP Printer attribute names as shown. | |
9288 | ||
9289 | In order to bridge between the directory service and the IPP Printer | |
9290 | object, one of the RECOMMENDED directory entry attributes is the | |
9291 | Printer object's "printer-uri-supported" attribute. The IPP client | |
9292 | queries the "printer-uri-supported" attribute in the directory entry | |
9293 | ||
9294 | ||
9295 | ||
9296 | ||
9297 | ||
9298 | deBry, et al. Experimental [Page 166] | |
9299 | \f | |
9300 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9301 | ||
9302 | ||
9303 | and then addresses the IPP Printer object using one of its URIs. The | |
9304 | "uri-security-supported" attribute identifies the protocol (if any) | |
9305 | used to secure a channel. | |
9306 | ||
9307 | The following attributes define the generic schema for directory | |
9308 | entries of type PRINTER: | |
9309 | ||
9310 | printer-uri-supported RECOMMENDED Section 4.4.1 | |
9311 | uri-security-supported RECOMMENDED Section 4.4.2 | |
9312 | printer-name RECOMMENDED Section 4.4.3 | |
9313 | printer-location RECOMMENDED Section 4.4.4 | |
9314 | printer-info OPTIONAL Section 4.4.5 | |
9315 | printer-more-info OPTIONAL Section 4.4.6 | |
9316 | printer-make-and-model RECOMMENDED Section 4.4.8 | |
9317 | charset-supported OPTIONAL Section 4.4.15 | |
9318 | generated-natural-language- | |
9319 | supported OPTIONAL Section 4.4.17 | |
9320 | document-format-supported RECOMMENDED Section 4.4.19 | |
9321 | color-supported RECOMMENDED Section 4.4.23 | |
9322 | finishings-supported OPTIONAL Section 4.2.6 | |
9323 | number-up-supported OPTIONAL Section 4.2.7 | |
9324 | sides-supported RECOMMENDED Section 4.2.8 | |
9325 | media-supported RECOMMENDED Section 4.2.11 | |
9326 | printer-resolution-supported OPTIONAL Section 4.2.12 | |
9327 | print-quality-supported OPTIONAL Section 4.2.13 | |
9328 | ||
9329 | ||
9330 | ||
9331 | ||
9332 | ||
9333 | ||
9334 | ||
9335 | ||
9336 | ||
9337 | ||
9338 | ||
9339 | ||
9340 | ||
9341 | ||
9342 | ||
9343 | ||
9344 | ||
9345 | ||
9346 | ||
9347 | ||
9348 | ||
9349 | ||
9350 | ||
9351 | ||
9352 | ||
9353 | ||
9354 | deBry, et al. Experimental [Page 167] | |
9355 | \f | |
9356 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9357 | ||
9358 | ||
9359 | 17. APPENDIX F: Change History for the IPP Model and Semantics document | |
9360 | ||
9361 | The following substantive changes and major clarifications have been | |
9362 | made to this document from the June 30, 1998 version based on the | |
9363 | interoperability testing that took place September 23-25 1998 and | |
9364 | subsequent mailing list and meeting discussions. They are listed in | |
9365 | the order of occurrence in the document. These changes are the ones | |
9366 | that might affect implementations. Clarifications that are unlikely | |
9367 | to affect implementations are not listed. The issue numbers refer to | |
9368 | the IPP Issues List which is available in the following directory: | |
9369 | ||
9370 | ftp://ftp.pwg.org/pub/pwg/ipp/approved-clarifications/ | |
9371 | ||
9372 | Section Description | |
9373 | ||
9374 | global Replaced TLS references with SSL3 references as agreed with | |
9375 | our Area Director on 11/12/1998. | |
9376 | ||
9377 | global Removed the indications that some of these IPP documents | |
9378 | are informational, since the intent is now to publish all | |
9379 | IPP/1.0 documents as informational as agreed with our Area | |
9380 | Director on 11/12/1998. | |
9381 | ||
9382 | 3.1.2, Clarify that the IPP object SHOULD NOT validate the | |
9383 | 16.3.3 range of the request-id being 1 to 2**31-1, but accepts | |
9384 | [now ipp- and returns any value. Clients MUST still keep in the | |
9385 | iig] range 1 to 2**31 though. If the request is terminated | |
9386 | before the complete "request-id" is received, the IPP | |
9387 | object rejects the request and returns a response with a | |
9388 | "request-id" of 0 (Issue 1.36). | |
9389 | ||
9390 | 3.1.4.1, Clarified that when a client submits a request in a | |
9391 | 13.1.4.14 charset that is not supported, the IPP object SHOULD | |
9392 | return any 'text' or 'name' attributes in the 'utf-8' | |
9393 | charset, if it returns any, since clients and IPP | |
9394 | objects MUST support 'utf-8'. (Issue 1.19) | |
9395 | ||
9396 | 3.1.4.1 Clarified Section 3.1.4.1 Request Operation Attributes | |
9397 | that a client MAY use the attribute level natural | |
9398 | language override (text/nameWithLanguage) redundantly in | |
9399 | a request. (Issue 1.46) | |
9400 | ||
9401 | 3.1.4.2 Clarified Section 3.1.4.2 Response Operation Attributes | |
9402 | that an IPP object MAY use the attribute level natural | |
9403 | language override (text/nameWithLanguage) redundantly in | |
9404 | a response. (Issue 1.46) | |
9405 | ||
9406 | ||
9407 | ||
9408 | ||
9409 | ||
9410 | deBry, et al. Experimental [Page 168] | |
9411 | \f | |
9412 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9413 | ||
9414 | ||
9415 | 3.1.6 Clarified section 3.1.6: If the Printer object supports | |
9416 | the "status-message" operation attribute, it NEED NOT | |
9417 | return a status message for the following error status | |
9418 | codes: 'client-error-bad-request', 'client-error- | |
9419 | charset-not-supported', 'server-error-internal-error', | |
9420 | 'server-error-operation-not-supported', and 'server- | |
9421 | error-version-not-supported'. | |
9422 | ||
9423 | 3.2.1.1 Clarified that if a client is not supplying any Job | |
9424 | Template attributes in a request, the client SHOULD omit | |
9425 | Group 2 rather than sending an empty group. However, a | |
9426 | Printer object MUST be able to accept an empty group. | |
9427 | This makes [RFC2566] agree with [RFC2565]. (Issue 1.16) | |
9428 | ||
9429 | 3.2.1.2, Clarified that if an IPP object is not returning any | |
9430 | 3.2.5.2, Unsupported Attributes in a response, the IPP object | |
9431 | 3.2.6.2, SHOULD omit Group 2 rather than sending an empty group. | |
9432 | 3.3.1.2, However, a client MUST be able to accept an empty group. | |
9433 | 3.3.3.2, This makes [RFC2566] agree with [RFC2565]. (Issue 1.17) | |
9434 | 3.3.4.2 | |
9435 | ||
9436 | 3.2.1.2, Clarified that an IPP object MUST treat an unsupported | |
9437 | 13.1.2.2, attribute syntax supplied in a request in the same way | |
9438 | 13.1.4.12 as an unsupported value. The IPP object MUST return the | |
9439 | attribute, the attribute syntax, and the value in the | |
9440 | Unsupported Attributes group. (Issue 1.26) | |
9441 | ||
9442 | 3.2.5.2, Clarified for Get-Printer-Attributes, Get-Jobs, and Get- | |
9443 | 3.2.6.2, Job-Attributes that an IPP object MUST return | |
9444 | 3.3.4.2, 'successful-ok-ignored-or-substituted-attributes' (0x1), | |
9445 | ||
9446 | 13.1.2.1, rather than 'successful-ok' (0x0), when a client | |
9447 | 13.1.2.2, supplies unsupported attributes as values of the | |
9448 | 13.1.4.12 'requested-attributes' operation attribute. (Issue | |
9449 | 1.24) | |
9450 | Also clarified that the response NEED NOT contain the | |
9451 | "requested-attributes" operation attribute with any | |
9452 | supplied values (attribute keywords) that were requested | |
9453 | by the client but are not supported by the IPP object. | |
9454 | (Issue 1.18) | |
9455 | ||
9456 | 3.2.6.2 Deleted the job-level natural language override (NLO) | |
9457 | 4.1.1.2 from Section 3.2.6.2 Get-Jobs Response so that all | |
9458 | 4.3.24 operation responses are the same with respect to NLO. | |
9459 | (Issue 1.47) | |
9460 | ||
9461 | ||
9462 | ||
9463 | ||
9464 | ||
9465 | ||
9466 | deBry, et al. Experimental [Page 169] | |
9467 | \f | |
9468 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9469 | ||
9470 | ||
9471 | 3.3.1 Clarified that an IPP Printer that supports the Create- | |
9472 | Job operation MUST handle the situation when a client | |
9473 | does not supply Send-Document or Send-URI operations | |
9474 | within a one- to four-minute time period. Also | |
9475 | clarified that a client MUST send documents in a multi- | |
9476 | document job without undue or unbounded delay. (Issue | |
9477 | 1.28) | |
9478 | ||
9479 | 3.3.3 Clarified that the IPP object MUST reject a Cancel-Job | |
9480 | request if the job is in 'completed', 'canceled', or | |
9481 | 'aborted' job states. (Issue 1.12) | |
9482 | ||
9483 | 4.1.2.3 Added this new sub-section: it specifies that | |
9484 | nameWithoutLanguage plus the implicit natural language | |
9485 | matches nameWithLanguage, if the values and natural | |
9486 | languages are the same. Also added that keyword never | |
9487 | matches nameWithLanguage or nameWithoutLanguage. | |
9488 | Clarified that if both have countries, that the | |
9489 | countries SHOULD match as well. If either do not, then | |
9490 | the country field SHOULD be ignored. (Issues 1.33 and | |
9491 | 1.34) | |
9492 | ||
9493 | 4.1.5 Clarified regarding the case-insensitivity of URLs to | |
9494 | refer only to the RFCs that define them. (Issue 1.10) | |
9495 | ||
9496 | 4.1.11 Clarified that 'boolean' is not a full-sized integer. | |
9497 | (Issue 1.38) | |
9498 | ||
9499 | 4.1.15 Clarified that 'resolution' is not three full-sized | |
9500 | integers. (Issue 1.20) | |
9501 | ||
9502 | 4.2.* Clarified that standard values are keywords or enums, | |
9503 | not names. (Issue 1.49). | |
9504 | ||
9505 | 4.2.4 Added the 'single-document-new-sheet' value to Section | |
9506 | 4.2.4 multiple-document-handling. (Issue 1.54) | |
9507 | ||
9508 | 4.4.18, Clarified that the "document-format-default" and | |
9509 | 4.4.19 "document-format-supported" Printer Description | |
9510 | attributes are REQUIRED to agree with the table. (Issue | |
9511 | 1.4) | |
9512 | ||
9513 | 4.4.21 Changed "queued-job-count" from OPTIONAL to RECOMMENDED. | |
9514 | (Issue 1.14) | |
9515 | ||
9516 | ||
9517 | ||
9518 | ||
9519 | ||
9520 | ||
9521 | ||
9522 | deBry, et al. Experimental [Page 170] | |
9523 | \f | |
9524 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9525 | ||
9526 | ||
9527 | 4.4.28 Clarified that the implementation supplied value for the | |
9528 | "multiple-operation-time-out" attribute SHOULD be | |
9529 | between 30 and 240 seconds, though the implementation | |
9530 | MAY allow the administrator to set values, and MAY allow | |
9531 | values outside this range. (Issue 1.28) | |
9532 | ||
9533 | 5.1, Clarified Client Conformance that if a client supports | |
9534 | 5.2.5 an attribute of 'text' attribute syntax, that it MUST | |
9535 | support both the textWithoutLanguage and the | |
9536 | textWithLanguage forms. Same for 'name' attribute | |
9537 | syntax. Same for an IPP object (Issue 1.48) | |
9538 | ||
9539 | 6.5, Added new section to allow Attribute Groups to be | |
9540 | 12.8 registered as extensions for being passed in operation | |
9541 | requests and responses. (Issue 1.25) | |
9542 | ||
9543 | 7. Updated the table of text and name attributes to agree | |
9544 | with Section 4.2. | |
9545 | ||
9546 | 8.5 Added a new section RECOMMENDING that the Get-Jobs | |
9547 | SHOULD return non-IPP jobs whether or not assigning them | |
9548 | a job-id and job-uri. Also RECOMMENDED generating, if | |
9549 | possible, job-id and job-uri and supporting other IPP | |
9550 | operations on foreign jobs as an implementer option. | |
9551 | (Issue 1.32) | |
9552 | ||
9553 | 9. Updated document references. | |
9554 | ||
9555 | 13.1.4.14 Clarified 'client-error-charset-not-supported' that | |
9556 | 'utf-8' must be used for any 'text' or 'name' attributes | |
9557 | returned in the error response (Issue 1.19). | |
9558 | ||
9559 | 13.1.5.9 Added a new error code 'server-error-job-canceled' | |
9560 | (0x0508) to be returned if a job is canceled by another | |
9561 | client or aborted by the IPP object while the first | |
9562 | client is still sending the document data. (Issue 1.29) | |
9563 | ||
9564 | 15.3, Moved these sections recommending operation processing | |
9565 | 15.4 steps to the new Implementer's Guide (informational). | |
9566 | There indicated that all of the error checks are not | |
9567 | required, so an IPP object MAY be forgiving and accept | |
9568 | non-conforming requests. However, a conforming client | |
9569 | MUST supply requests that would pass all of the error | |
9570 | checks indicated. (Issue 1.21) | |
9571 | ||
9572 | ||
9573 | ||
9574 | ||
9575 | ||
9576 | ||
9577 | ||
9578 | deBry, et al. Experimental [Page 171] | |
9579 | \f | |
9580 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9581 | ||
9582 | ||
9583 | 16 Changed directory schema attributes from REQUIRED to | |
9584 | RECOMMENDED. Changed some of the OPTIONAL to | |
9585 | RECOMMENDED to agree with the SLP template. Changed the | |
9586 | "charset-supported" and "natural-language-supported" | |
9587 | from REQUIRED to OPTIONAL. Recommended that the names | |
9588 | be the same in a directory entry as the IPP attribute | |
9589 | names. (Issue 1.53) | |
9590 | ||
9591 | ||
9592 | ||
9593 | ||
9594 | ||
9595 | ||
9596 | ||
9597 | ||
9598 | ||
9599 | ||
9600 | ||
9601 | ||
9602 | ||
9603 | ||
9604 | ||
9605 | ||
9606 | ||
9607 | ||
9608 | ||
9609 | ||
9610 | ||
9611 | ||
9612 | ||
9613 | ||
9614 | ||
9615 | ||
9616 | ||
9617 | ||
9618 | ||
9619 | ||
9620 | ||
9621 | ||
9622 | ||
9623 | ||
9624 | ||
9625 | ||
9626 | ||
9627 | ||
9628 | ||
9629 | ||
9630 | ||
9631 | ||
9632 | ||
9633 | ||
9634 | deBry, et al. Experimental [Page 172] | |
9635 | \f | |
9636 | RFC 2566 IPP/1.0: Model and Semantics April 1999 | |
9637 | ||
9638 | ||
9639 | 18. Full Copyright Statement | |
9640 | ||
9641 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
9642 | ||
9643 | This document and translations of it may be copied and furnished to | |
9644 | others, and derivative works that comment on or otherwise explain it | |
9645 | or assist in its implementation may be prepared, copied, published | |
9646 | and distributed, in whole or in part, without restriction of any | |
9647 | kind, provided that the above copyright notice and this paragraph are | |
9648 | included on all such copies and derivative works. However, this | |
9649 | document itself may not be modified in any way, such as by removing | |
9650 | the copyright notice or references to the Internet Society or other | |
9651 | Internet organizations, except as needed for the purpose of | |
9652 | developing Internet standards in which case the procedures for | |
9653 | copyrights defined in the Internet Standards process must be | |
9654 | followed, or as required to translate it into languages other than | |
9655 | English. | |
9656 | ||
9657 | The limited permissions granted above are perpetual and will not be | |
9658 | revoked by the Internet Society or its successors or assigns. | |
9659 | ||
9660 | This document and the information contained herein is provided on an | |
9661 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
9662 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
9663 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
9664 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
9665 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
9666 | ||
9667 | ||
9668 | ||
9669 | ||
9670 | ||
9671 | ||
9672 | ||
9673 | ||
9674 | ||
9675 | ||
9676 | ||
9677 | ||
9678 | ||
9679 | ||
9680 | ||
9681 | ||
9682 | ||
9683 | ||
9684 | ||
9685 | ||
9686 | ||
9687 | ||
9688 | ||
9689 | ||
9690 | deBry, et al. Experimental [Page 173] | |
9691 | \f |