]> git.ipfire.org Git - thirdparty/cups.git/blame - standards/rfc3196.txt
projects / thirdparty / cups.git / blame
? search:
summary | shortlog | log | commit | commitdiff | tree
blob | blame (incremental) | history | HEAD
Merge changes from CUPS 1.4svn-r7696.
[thirdparty/cups.git] / standards / rfc3196.txt
CommitLineData
fa73b229 1
2
3
4
5
6
7Network Working Group T. Hastings
8Request for Comments: 3196 C. Manros
9Obsoletes: 2639 P. Zehler
10Category: Informational Xerox Corporation
11 C. Kugler
12 IBM Printing Systems Co
13 H. Holst
14 i-data Printing Systems
15 November 2001
16
17
18 Internet Printing Protocol/1.1: Implementor's Guide
19
20Status of this Memo
21
22 This memo provides information for the Internet community. It does
23 not specify an Internet standard of any kind. Distribution of this
24 memo is unlimited.
25
26Copyright Notice
27
28 Copyright (C) The Internet Society (2001). All Rights Reserved.
29
30Abstract
31
32 This document is one of a set of documents, which together describe
33 all aspects of a new Internet Printing Protocol (IPP).
34
35Table of Contents
36
37 1 Introduction................................................... 4
38 1.1 Conformance language........................................ 5
39 1.2 Other terminology........................................... 6
40 1.3 Issues Raised from Interoperability Testing Events.......... 6
41 2 IPP Objects.................................................... 6
42 3 IPP Operations................................................. 7
43 3.1 Common Semantics............................................ 7
44 3.1.1 Summary of Operation Attributes............................ 8
45 3.1.2 Suggested Operation Processing Steps for IPP Objects....... 16
46 3.1.2.1 Suggested Operation Processing Steps for all Operations. 17
47 3.1.2.1.1 Validate version number............................... 18
48 3.1.2.1.2 Validate operation identifier......................... 20
49 3.1.2.1.3 Validate the request identifier....................... 20
50 3.1.2.1.4 Validate attribute group and attribute presence and
51 order................................................. 20
52 3.1.2.1.4.1 Validate the presence and order of attribute groups. 20
53 3.1.2.1.4.2 Ignore unknown attribute groups in the expected
54 position............................................ 21
55
56
57
58Hastings, et al. Informational [Page 1]
59\f
60RFC 3196 Internet Printing Protocol/1.1 November 2001
61
62
63 3.1.2.1.4.3 Validate the presence of a single occurrence of
64 required Operation attributes....................... 21
65 3.1.2.1.5 Validate the values of the REQUIRED Operation
66 attributes............................................ 29
67 3.1.2.1.6 Validate the values of the OPTIONAL Operation
68 attributes............................................ 33
69 3.1.2.2 Suggested Additional Processing Steps for Operations
70 that Create/Validate Jobs and Add Documents............. 37
71 3.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied...... 37
72 3.1.2.2.2 Check that the Printer object is accepting jobs....... 38
73 3.1.2.2.3 Validate the values of the Job Template attributes.... 38
74 3.1.2.3 Algorithm for job validation............................ 39
75 3.1.2.3.1 Check for conflicting Job Template attributes values.. 45
76 3.1.2.3.2 Decide whether to REJECT the request.................. 46
77 3.1.2.3.3 For the Validate-Job operation, RETURN one of the
78 success status codes.................................. 48
79 3.1.2.3.4 Create the Job object with attributes to support...... 48
80 3.1.2.3.5 Return one of the success status codes................ 50
81 3.1.2.3.6 Accept appended Document Content...................... 50
82 3.1.2.3.7 Scheduling and Starting to Process the Job............ 50
83 3.1.2.3.8 Completing the Job.................................... 50
84 3.1.2.3.9 Destroying the Job after completion................... 51
85 3.1.2.3.10 Interaction with "ipp-attribute-fidelity"............. 51
86 3.1.2.3.11 Character set code conversion support................. 51
87 3.1.2.3.12 What charset to return when an unsupported charset is
88 requested (Issue 1.19)?....... ....................... 52
89 3.1.2.3.13 Natural Language Override (NLO)....................... 53
90 3.1.3 Status codes returned by operation......................... 55
91 3.1.3.1 Printer Operations...................................... 55
92 3.1.3.1.1 Print-Job............................................. 55
93 3.1.3.1.2 Print-URI............................................. 58
94 3.1.3.1.3 Validate-Job.......................................... 58
95 3.1.3.1.4 Create-Job............................................ 58
96 3.1.3.1.5 Get-Printer-Attributes................................ 59
97 3.1.3.1.6 Get-Jobs.............................................. 60
98 3.1.3.1.7 Pause-Printer......................................... 61
99 3.1.3.1.8 Resume-Printer........................................ 62
100 3.1.3.1.8.1 What about Printers unable to change state due to
101 an error condition?................................. 63
102 3.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?... 63
103 3.1.3.1.9 Purge-Printer......................................... 63
104 3.1.3.2 Job Operations.......................................... 64
105 3.1.3.2.1 Send-Document......................................... 64
106 3.1.3.2.2 Send-URI.............................................. 65
107 3.1.3.2.3 Cancel-Job............................................ 65
108 3.1.3.2.4 Get-Job-Attributes.................................... 67
109 3.1.3.2.5 Hold-Job.............................................. 68
110 3.1.3.2.6 Release-Job........................................... 69
111
112
113
114Hastings, et al. Informational [Page 2]
115\f
116RFC 3196 Internet Printing Protocol/1.1 November 2001
117
118
119 3.1.3.2.7 Restart-Job........................................... 69
120 3.1.3.2.7.1 Can documents be added to a restarted job?.......... 69
121 3.1.4 Returning unsupported attributes in Get-Xxxx responses
122 (Issue 1.18)............................................... 70
123 3.1.5 Sending empty attribute groups............................. 70
124 3.2 Printer Operations.......................................... 71
125 3.2.1 Print-Job operation........................................ 71
126 3.2.1.1 Flow controlling the data portion of a Print-Job
127 request (Issue 1.22).................................... 71
128 3.2.1.2 Returning job-state in Print-Job response (Issue 1.30).. 71
129 3.2.2 Get-Printer-Attributes operation........................... 72
130 3.2.3 Get-Jobs operation......................................... 72
131 3.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name'
132 (Issue 1.39)?.......................................... 72
133 3.2.3.2 Why is there a "limit" attribute in the Get-Jobs
134 operation?.............................................. 73
135 3.2.4 Create-Job operation....................................... 73
136 3.3 Job Operations.............................................. 74
137 3.3.1 Validate-Job............................................... 74
138 3.3.2 Restart-Job................................................ 74
139 4 Object Attributes.............................................. 74
140 4.1 Attribute Syntax's.......................................... 74
141 4.1.1 The 'none' value for empty sets (Issue 1.37)............... 74
142 4.1.2 Multi-valued attributes (Issue 1.31)....................... 75
143 4.1.3 Case Sensitivity in URIs (issue 1.6)....................... 75
144 4.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage.. 76
145 4.2 Job Template Attributes..................................... 76
146 4.2.1 multiple-document-handling(type2 keyword).................. 76
147 4.2.1.1 Support of multiple document jobs....................... 76
148 4.3 Job Description Attributes.................................. 76
149 4.3.1 Getting the date and time of day........................... 76
150 4.4 Printer Description Attributes.............................. 77
151 4.4.1 queued-job-count (integer(0:MAX)).......................... 77
152 4.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?..... 77
153 4.4.1.2 Is "queued-job-count" a good measure of how busy a
154 printer is (Issue 1.15)?................................ 77
155 4.4.2 printer-current-time (dateTime)............................ 78
156 4.4.3 Printer-uri................................................ 78
157 4.5 Empty Jobs.................................................. 79
158 5 Directory Considerations....................................... 79
159 5.1 General Directory Schema Considerations..................... 79
160 5.2 IPP Printer with a DNS name................................. 79
161 6 Security Considerations........................................ 80
162 6.1 Querying jobs with IPP that were submitted using other job
163 submission protocols (Issue 1.32)........................... 80
164 7 Encoding and Transport......................................... 81
165 7.1 General Headers............................................. 83
166 7.2 Request Headers............................................ 84
167
168
169
170Hastings, et al. Informational [Page 3]
171\f
172RFC 3196 Internet Printing Protocol/1.1 November 2001
173
174
175 7.3 Response Headers............................................ 86
176 7.4 Entity Headers............................................. 87
177 7.5 Optional support for HTTP/1.0............................... 88
178 7.6 HTTP/1.1 Chunking........................................... 88
179 7.6.1 Disabling IPP Server Response Chunking..................... 88
180 7.6.2 Warning About the Support of Chunked Requests.............. 88
181 8 References..................................................... 89
182 9 Authors' Addresses............................................. 91
183 10 Description of the Base IPP Documents.......................... 94
184 11 Full Copyright Statement....................................... 96
185
186Tables
187
188 Table 1 - Summary of Printer operation attributes that sender MUST
189 supply ................................................. 8
190 Table 2 - Summary of Printer operation attributes that sender MAY
191 supply ................................................. 10
192 Table 3 - Summary of Job operation attributes that sender MUST
193 supply.................................................. 12
194 Table 4 - Summary of Job operation attributes that sender MAY
195 supply.................................................. 14
196 Table 5 - Printer operation response attributes................... 16
197 Table 6 - Examples of validating IPP version...................... 19
198 Table 7 - Rules for validating single values X against Z.......... 40
199
2001. Introduction
201
202 IPP is an application level protocol that can be used for distributed
203 printing using Internet tools and technologies. This document
204 contains information that supplements the IPP Model and Semantics
205 [RFC2911] and the IPP Transport and Encoding [RFC2910] documents. It
206 is intended to help implementers understand IPP/1.1, as well as
207 IPP/1.0 [RFC2565, RFC2566], and some of the considerations that may
208 assist them in the design of their client and/or IPP object
209 implementation. For example, a typical order of processing requests
210 is given, including error checking. Motivation for some of the
211 specification decisions is also included.
212
213 This document obsoletes RFC 2639 which was the Implementor's Guide
214 for IPP/1.0. The IPP Implementor's Guide (IIG) (this document)
215 contains information that supplements the IPP Model and Semantics
216 [RFC2911] and the IPP Transport and Encoding [RFC2910] documents.
217 This document is just one of a suite of documents that fully define
218 IPP. The base set of IPP documents includes:
219
220 Design Goals for an Internet Printing Protocol [RFC2567]
221 Rationale for the Structure and Model and Protocol for the
222 Internet Printing Protocol [RFC2568]
223
224
225
226Hastings, et al. Informational [Page 4]
227\f
228RFC 3196 Internet Printing Protocol/1.1 November 2001
229
230
231 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
232 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
233 Internet Printing Protocol/1.1: Implementor's Guide (this
234 document)
235 Mapping between LPD and IPP Protocols [RFC2569]
236
237 See section 10 for a description of these base IPP documents. Anyone
238 reading these documents for the first time is strongly encouraged to
239 read the IPP documents in the above order.
240
241 As such the information in this document is not part of the formal
242 specification of IPP/1.1. Instead information is presented to help
243 implementers understand IPP/1.1, as well as IPP/1.0 [RFC2565,
244 RFC2566], including some of the motivation for decisions taken by the
245 committee in developing the specification. Some of the
246 implementation considerations are intended to help implementers
247 design their client and/or IPP object implementations. If there are
248 any contradictions between this document and [RFC2911] or [RFC2910],
249 those documents take precedence over this document.
250
251 Platform-specific implementation considerations will be included in
252 this guide as they become known.
253
254 Note: In order to help the reader of the IIG and the IPP Model and
255 Semantics document, the sections in this document parallel the
256 corresponding sections in the Model document and are numbered the
257 same for ease of cross reference. The sections that correspond to
258 the IPP Transport and Encoding are correspondingly offset.
259
2601.1 Conformance language
261
262 Usually, this document does not contain the terminology MUST, MUST
263 NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
264 However, when those terms do appear in this document, their intent is
265 to repeat what the [RFC2911] and [RFC2910] documents require and
266 allow, rather than specifying additional conformance requirements.
267 These terms are defined in section 12 on conformance terminology in
268 [RFC2911], most of which is taken from RFC 2119 [RFC2119].
269
270 Implementers should read section 12 (APPENDIX A) in [RFC2911] in
271 order to understand these capitalized words. The words MUST, MUST
272 NOT, and REQUIRED indicate what implementations are required to
273 support in a client or IPP object in order to be conformant to
274 [RFC2911] and [RFC2910]. MAY, NEED NOT, and OPTIONAL indicate was is
275 merely allowed as an implementer option. The verbs SHOULD and SHOULD
276 NOT indicate suggested behavior, but which is not required or
277 disallowed, respectively, in order to conform to the specification.
278
279
280
281
282Hastings, et al. Informational [Page 5]
283\f
284RFC 3196 Internet Printing Protocol/1.1 November 2001
285
286
2871.2 Other terminology
288
289 This document uses other terms, such as "attributes", "operation",
290 and "Printer" as defined in [RFC2911] section 12. In addition, the
291 term "sender" refers to the client that sends a request or an IPP
292 object that returns a response. The term "receiver" refers to the
293 IPP object that receives a request and to a client that receives a
294 response.
295
2961.3 Issues Raised from Interoperability Testing Events
297
298 The IPP WG has conducted three open Interoperability Testing Events.
299 The first one was held in September 1998, the second one was held in
300 March 1999, and the third one was held in October 2000. See the
301 summary reports in:
302
303 ftp://ftp.pwg.org/pub/pwg/ipp/new_TES/
304
305 The issues raised from the first Interoperability Testing Event are
306 numbered 1.n in this document and have been incorporated into
307 "IPP/1.0 Model and Semantics" [RFC2566] and the "IPP/1.0 Encoding and
308 Transport" [RFC2565] documents. However, some of the discussion is
309 left here in the Implementor's Guide to help understanding.
310
311 The issues raised from the second Interoperability Testing Event are
312 numbered 2.n in this document have been incorporated into "IPP/1.1
313 Model and Semantics" [RFC2911] and the "IPP/1.1 Encoding and
314 Transport" [RFC2910] documents. However, some of the discussion is
315 left here in the Implementor's Guide to help understanding.
316
317 The issues raised from the third Interoperability Testing Event are
318 numbered 3.n in this document and are described in:
319
320 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
321 Off3.pdf
322
323 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
324 Off3.doc
325
326 ftp://ftp.pwg.org/pub/pwg/ipp/Issues/Issues-raised-at-Bake-
327 Off3.txt
328
329
330
331
332
333
334
335
336
337
338Hastings, et al. Informational [Page 6]
339\f
340RFC 3196 Internet Printing Protocol/1.1 November 2001
341
342
3432. IPP Objects
344
345 The term "client" in IPP is intended to mean any client that issues
346 IPP operation requests and accepts IPP operation responses, whether
347 it be a desktop or a server. In other words, the term "client" does
348 not just mean end-user clients, such as those associated with
349 desktops.
350
351 The term "IPP Printer" in IPP is intended to mean an object that
352 accepts IPP operation requests and returns IPP operation responses,
353 whether implemented in a server or a device. An IPP Printer object
354 MAY, if implemented in a server, turn around and forward received
355 jobs (and other requests) to other devices and print
356 servers/services, either using IPP or some other protocol.
357
3583 IPP Operations
359
360 This section corresponds to Section 3 "IPP Operations" in the
361 IPP/1.1 Model and Semantics document [RFC2911].
362
3633.1 Common Semantics
364
365 This section discusses semantics common to all operations.
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394Hastings, et al. Informational [Page 7]
395\f
396RFC 3196 Internet Printing Protocol/1.1 November 2001
397
398
3993.1.1 Summary of Operation Attributes
400
401 Table 1 - Summary of Printer operation attributes that sender MUST
402 supply
403
404Printer Operations
405
406 Requests Responses
407 Operation PJ, PU CJ GPA GJ PP, All
408 Attributes VJ (O) (O) (R) (R) RP, Operations
409 (R) PP
410 (O+)
411
412 Operation parameters--REQUIRED to be supplied by the sender:
413
414 operation-id R R R R R R
415
416 status-code R
417
418 request-id R R R R R R R
419
420 version-number R R R R R R R
421
422 Operation attributes--REQUIRED to be supplied by the sender:
423
424 attributes- R R R R R R R
425 charset
426
427 attributes- R R R R R R R
428 natural-
429 language
430
431 document-uri R
432
433 job-id*
434
435 job-uri*
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450Hastings, et al. Informational [Page 8]
451\f
452RFC 3196 Internet Printing Protocol/1.1 November 2001
453
454
455Printer Operations
456
457 Requests Responses
458
459 Operation PJ, PU CJ GPA GJ PP, All
460 Attributes VJ (O) (O) (R) (R) RP, Operations
461 (R) PP
462 (O+)
463 last-document
464
465 printer-uri R R R R R R
466
467 Operation attributes--RECOMMENDED to be supplied by the
468 sender:
469
470 job-name R R R
471
472 requesting-user- R R R R R R
473 name
474
475 Legend:
476
477 PJ, VJ: Print-Job, Validate-Job
478 PU: Print-URI
479 CJ: Create-Job
480 GPA: Get-Printer-Attributes
481 GJ: Get-Jobs
482 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
483 R indicates a REQUIRED operation that MUST be supported by the IPP
484 object (Printer or Job). For attributes, R indicates that the
485 attribute MUST be supported by the IPP object that supports the
486 associated operation.
487 O indicates an OPTIONAL operation or attribute that MAY be supported
488 by the IPP object (Printer or Job).
489 + indicates that this is not an IPP/1.0 feature, but is only a part
490 of IPP/1.1 and future versions of IPP.
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506Hastings, et al. Informational [Page 9]
507\f
508RFC 3196 Internet Printing Protocol/1.1 November 2001
509
510
511 Table 2 - Summary of Printer operation attributes that sender MAY
512 supply
513
514Printer Operations
515
516 Requests Respon-
517 ses
518 Operation Attributes PJ, PU CJ GPA GJ PP, All
519 VJ (O) (O) (R) (R) RP, Opera
520 (R) PP tions
521 (O+)
522
523 Operation attributes--OPTIONAL to be supplied by the sender:
524
525 status-message O
526
527 detailed-status- O
528 message
529
530 document-access- O**
531 error
532
533 compression R R
534
535 document-format R R R
536
537 document-name O O
538
539 document-natural- O O
540 language
541
542 ipp-attribute- R R R
543 fidelity
544
545 job-impressions O O O
546
547 job-k-octets O O O
548
549 job-media-sheets O O O
550
551
552
553
554
555
556
557
558
559
560
561
562Hastings, et al. Informational [Page 10]
563\f
564RFC 3196 Internet Printing Protocol/1.1 November 2001
565
566
567Printer Operations
568
569 Requests Respon-
570 ses
571 Operation Attributes PJ, PU CJ GPA GJ PP, All
572 VJ (O) (O) (R) (R) RP, Opera
573 (R) PP tions
574 (O+)
575
576 limit R
577
578 message
579
580 my-jobs R
581
582 requested-attributes R R
583
584 which-jobs R
585
586 Legend:
587
588 PJ, VJ: Print-Job, Validate-Job
589 PU: Print-URI
590 CJ: Create-Job
591 GPA: Get-Printer-Attributes
592 GJ: Get-Jobs
593 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
594 R indicates a REQUIRED operation that MUST be supported by the IPP
595 object (Printer or Job). For attributes, R indicates that the
596 attribute MUST be supported by the IPP object that supports the
597 associated operation.
598 O indicates an OPTIONAL operation or attribute that MAY be supported
599 by the IPP object (Printer or Job).
600 + indicates that this is not an IPP/1.0 feature, but is only a part
601 of IPP/1.1 and future versions of IPP.
602 * "job-id" is REQUIRED only if used together with "printer-uri" to
603 identify the target job; otherwise, "job-uri" is REQUIRED.
604 ** "document-access-error" applies to the Print-URI response only.
605
606
607
608
609
610
611
612
613
614
615
616
617
618Hastings, et al. Informational [Page 11]
619\f
620RFC 3196 Internet Printing Protocol/1.1 November 2001
621
622
623 Table 3 - Summary of Job operation attributes that sender MUST supply
624
625Job Operations
626
627 Requests Responses
628 Operation SD SU CJ GJA HJ All
629 Attributes (O) (O) (R) (R) RJ, RJ Opera-
630 (O+) tions
631
632 Operation parameters--REQUIRED to be supplied by the sender:
633
634 operation-id R R R R R
635
636 status-code R
637
638 request-id R R R R R R
639
640 version-number R R R R R R
641
642 Operation attributes--REQUIRED to be supplied by the sender:
643
644 attributes-charset R R R R R R
645
646 attributes-natural- R R R R R R
647 language
648
649 document-uri R
650
651 job-id* R R R R R
652
653 job-uri* R R R R R
654
655 last-document R R
656
657 printer-uri R R R R R
658
659 Operation attributes--RECOMMENDED to be supplied by the sender:
660
661 job-name
662
663
664
665
666
667
668
669
670
671
672
673
674Hastings, et al. Informational [Page 12]
675\f
676RFC 3196 Internet Printing Protocol/1.1 November 2001
677
678
679Job Operations
680
681 Requests Responses
682
683 Operation SD SU CJ GJA HJ All
684 Attributes (O) (O) (R) (R) RJ, RJ Opera-
685 (O+) tions
686
687 requesting-user- R R R R R
688 name
689
690 Legend:
691
692 SD: Send-Document
693 SU: Send-URI
694 CJ: Cancel-Job
695 GJA: Get-Job-Attributes
696 HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
697 R indicates a REQUIRED operation that MUST be supported by the IPP
698 object (Printer or Job). For attributes, R indicates that the
699 attribute MUST be supported by the IPP object that supports the
700 associated operation.
701 O indicates an OPTIONAL operation or attribute that MAY be supported
702 by the IPP object (Printer or Job).
703 + indicates that this is not an IPP/1.0 feature, but is only a part
704 of IPP/1.1 and future versions of IPP.
705 * "job-id" is REQUIRED only if used together with "printer-uri" to
706 identify the target job; otherwise, "job-uri" is REQUIRED.
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730Hastings, et al. Informational [Page 13]
731\f
732RFC 3196 Internet Printing Protocol/1.1 November 2001
733
734
735 Table 4 - Summary of Job operation attributes that sender MAY supply
736
737Job Operations
738
739 Requests Responses
740
741 Operation SD SU CJ GJA HJ, SD All
742 Attributes (O) (O) (R) (R) RJ, (O) Opera-
743 RJ tions
744 (O+)
745
746 Operation attributes--OPTIONAL to be supplied by the sender:
747
748 status-message O
749
750 detailed-status- O
751 message
752
753 document-access- O**
754 error
755
756 compression R R
757
758 document-format R R
759
760 document-name O O
761
762 document-natural- O O
763 language
764
765 ipp-attribute-
766 fidelity
767
768 job-impressions
769
770 job-k-octets
771
772 job-media-sheets
773
774
775
776
777
778
779
780
781
782
783
784
785
786Hastings, et al. Informational [Page 14]
787\f
788RFC 3196 Internet Printing Protocol/1.1 November 2001
789
790
791Job Operations
792
793 Requests Responses
794
795 Operation SD SU CJ GJA HJ, SD All
796 Attributes (O) (O) (R) (R) RJ, (O) Opera-
797 RJ tions
798 (O+)
799
800 limit
801
802 message O O O
803
804 job-hold-until R
805
806 my-jobs
807
808 requested- R
809 attributes
810
811 which-jobs
812
813 Legend:
814
815 SD: Send-Document
816 SU: Send-URI
817 CJ: Cancel-Job
818 GJA: Get-Job-Attributes
819 HJ, RJ, RJ: Hold-Job, Release-Job, Restart-Job
820 R indicates a REQUIRED operation that MUST be supported by the IPP
821 object (Printer or Job). For attributes, R indicates that the
822 attribute MUST be supported by the IPP object that supports the
823 associated operation.
824 O indicates an OPTIONAL operation or attribute that MAY be supported
825 by the IPP object (Printer or Job).
826 + indicates that this is not an IPP/1.0 feature, but is only a part
827 of IPP/1.1 and future versions of IPP.
828 * "job-id" is REQUIRED only if used together with "printer-uri" to
829 identify the target job; otherwise, "job-uri" is REQUIRED.
830 ** "document-access-error" applies to the Send-URI operation only
831
832
833
834
835
836
837
838
839
840
841
842Hastings, et al. Informational [Page 15]
843\f
844RFC 3196 Internet Printing Protocol/1.1 November 2001
845
846
847 Table 5 - Printer operation response attributes
848
849Printer Operations
850
851 Response
852
853 Operation PJ (R) VJ (R) PU (O) CJ (O) GPA GJ (R) PP,
854 Attributes SD (O) SU (O) (R) RP, PP
855 (O+)
856
857 job-uri R R R
858
859 job-id R R R
860
861 job-state R R R
862
863 job-state- R+ R+ R+
864 reasons
865
866 number-of- O O O
867 intervening-
868 jobs
869
870 document- O
871 access-
872 error+
873
874 Legend:
875
876 PJ, SJ: Print-Job, Send-Document
877 VJ: Validate-Job
878 PU, SU: Print-URI, Send-URI
879 CJ: Create-Job
880 GPA: Get-Printer-Attributes
881 GJ: Get-Jobs
882 PP, RP, PP: Pause-Printer, Resume-Printer, Purge-Printer
883 R indicates a REQUIRED operation that MUST be supported by the IPP
884 object (Printer or Job). For attributes, R indicates that the
885 attribute MUST be supported by the IPP object that supports the
886 associated operation.
887 O indicates an OPTIONAL operation or attribute that MAY be supported
888 by the IPP object (Printer or Job).
889
8903.1.2 Suggested Operation Processing Steps for IPP Objects
891
892 This section suggests the steps and error checks that an IPP object
893 MAY perform when processing requests and returning responses. An IPP
894 object MAY perform some or all of the error checks. However, some
895
896
897
898Hastings, et al. Informational [Page 16]
899\f
900RFC 3196 Internet Printing Protocol/1.1 November 2001
901
902
903 implementations MAY choose to be more forgiving than the error checks
904 shown here, in order to be able to accept requests from non-
905 conforming clients. Not performing all of these error checks is a
906 so-called "forgiving" implementation. On the other hand, clients
907 that successfully submit requests to IPP objects that do perform all
908 the error checks will be more likely to be able to interoperate with
909 other IPP object implementations. Thus an implementer of an IPP
910 object needs to decide whether to be a "forgiving" or a "strict"
911 implementation. Therefore, the error status codes returned may
912 differ between implementations. Consequentially, client SHOULD NOT
913 expect exactly the error code processing described in this section.
914
915 When an IPP object receives a request, the IPP object either accepts
916 or rejects the request. In order to determine whether or not to
917 accept or reject the request, the IPP object SHOULD execute the
918 following steps. The order of the steps may be rearranged and/or
919 combined, including making one or multiple passes over the request.
920
921 A client MUST supply requests that would pass all of the error checks
922 indicated here in order to be a conforming client. Therefore, a
923 client SHOULD supply requests that are conforming, in order to avoid
924 being rejected by some IPP object implementations and/or risking
925 different semantics by different implementations of forgiving
926 implementations. For example, a forgiving implementation that
927 accepts multiple occurrences of the same attribute, rather than
928 rejecting the request might use the first occurrences, while another
929 might use the last occurrence. Thus such a non-conforming client
930 would get different results from the two forgiving implementations.
931
932 In the following, processing continues step by step until a "RETURNS
933 the xxx status code ..." statement is encountered. Error returns are
934 indicated by the verb: "REJECTS". Since clients have difficulty
935 getting the status code before sending all of the document data in a
936 Print-Job request, clients SHOULD use the Validate-Job operation
937 before sending large documents to be printed, in order to validate
938 whether the IPP Printer will accept the job or not.
939
940 It is assumed that security authentication and authorization has
941 already taken place at a lower layer.
942
9433.1.2.1 Suggested Operation Processing Steps for all Operations
944
945 This section is intended to apply to all operations. The next
946 section contains the additional steps for the Print-Job, Validate-
947 Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
948 that create jobs, adds documents, and validates jobs.
949
950
951
952
953
954Hastings, et al. Informational [Page 17]
955\f
956RFC 3196 Internet Printing Protocol/1.1 November 2001
957
958
959 IIG Sect # Flow IPP error status codes
960 ---------- ---- ----------------------
961 |
962 v err
963 3.1.2.1.1 <Validate version> --> server-error-version-not-
964 supported
965 ok|
966 v err
967 3.1.2.1.2 <Validate operation> --> server-error-operation-not-
968 supported
969 ok|
970 v err
971 3.1.2.1.4.1- <Validate presence> --> client-error-bad-request
972 3.1.2.1.4.2 <of attributes>
973 ok|
974 v err
975 3.1.2.1.4.3 <Validate presence> --> client-error-bad-request
976 <of operation attr>
977 ok|
978 v err
979 3.1.2.1.5 <Validate values of> --> client-error-bad-request
980 <operation attrs> client-error-request-value-
981 too-long
982 <(length, tag, range,>
983 <multi-value)>
984 ok|
985 v err
986 3.1.2.1.5 <Validate values> --> client-error-bad-request
987 <with supported values> client-error-charset-not-
988 supported
989 ok| client-error-attributes-or-
990 values-
991 | not-supported
992 v err
993 3.1.2.1.6 <Validate optionally> --> client-error-bad-request
994 <operation attr> client-error-natural-language-
995 not-supported
996 | client-error-request-value-
997 too-long
998 | client-error-attributes-or-
999 values-not-supported
1000
10013.1.2.1.1 Validate version number
1002
1003 Every request and every response contains the "version-number"
1004 attribute. The value of this attribute is the major and minor
1005 version number of the syntax and semantics that the client and IPP
1006 object is using, respectively. The "version-number" attribute
1007
1008
1009
1010Hastings, et al. Informational [Page 18]
1011\f
1012RFC 3196 Internet Printing Protocol/1.1 November 2001
1013
1014
1015 remains in a fixed position across all future versions so that all
1016 clients and IPP object that support future versions can determine
1017 which version is being used. The IPP object checks to see if the
1018 major version number supplied in the request is supported. If not,
1019 the Printer object REJECTS the request and RETURNS the 'server-
1020 error-version-not-supported' status code in the response. The IPP
1021 object returns in the "version-number" response attribute the major
1022 and minor version for the error response. Thus the client can learn
1023 at least one major and minor version that the IPP object supports.
1024 The IPP object is encouraged to return the closest version number to
1025 the one supplied by the client.
1026
1027 The checking of the minor version number is implementation dependent,
1028 however if the client-supplied minor version is explicitly supported,
1029 the IPP object MUST respond using that identical minor version
1030 number. If the major version number matches, but the minor version
1031 number does not, the Printer SHOULD accept and attempt to process the
1032 request, or MAY reject the request and return the 'server-error-
1033 version-not-supported' status code. In all cases, the Printer MUST
1034 return the nearest version number that it supports. For example,
1035 suppose that an IPP/1.2 Printer supports versions '1.1' and '1.2'.
1036 The following responses are conforming:
1037
1038 Table 6 - Examples of validating IPP version
1039
1040 Client supplies Printer Accept Request? Printer returns
1041
1042
1043 1.0 yes (SHOULD) 1.1
1044
1045 1.0 no (SHOULD NOT) 1.1
1046
1047 1.1 yes (MUST) 1.1
1048
1049 1.2 yes (MUST) 1.2
1050
1051 1.3 yes (SHOULD) 1.2
1052
1053 1.3 no (SHOULD NOT) 1.2
1054
1055 It is advantageous for Printers to support both IPP/1.1 and IPP/1.0,
1056 so that they can interoperate with either client implementations.
1057 Some implementations may allow an Administrator to explicitly disable
1058 support for one or the other by setting the "ipp-versions-supported"
1059 Printer description attribute.
1060
1061
1062
1063
1064
1065
1066Hastings, et al. Informational [Page 19]
1067\f
1068RFC 3196 Internet Printing Protocol/1.1 November 2001
1069
1070
1071 Likewise, it is advantageous for clients to support both versions to
1072 allow interoperability with new and legacy Printers.
1073
10743.1.2.1.2 Validate operation identifier
1075
1076 The Printer object checks to see if the "operation-id" attribute
1077 supplied by the client is supported as indicated in the Printer
1078 object's "operations-supported" attribute. If not, the Printer
1079 REJECTS the request and returns the 'server-error-operation-not-
1080 supported' status code in the response.
1081
10823.1.2.1.3 Validate the request identifier
1083
1084 The Printer object SHOULD NOT check to see if the "request-id"
1085 attribute supplied by the client is in range: between 1 and 2**31 - 1
1086 (inclusive), but copies all 32 bits.
1087
1088 Note: The "version-number", "operation-id", and the "request-id"
1089 parameters are in fixed octet positions in the IPP/1.1 encoding. The
1090 "version-number" parameter will be the same fixed octet position in
1091 all versions of the protocol. These fields are validated before
1092 proceeding with the rest of the validation.
1093
10943.1.2.1.4 Validate attribute group and attribute presence and order
1095
1096 The order of the following validation steps depends on
1097 implementation.
1098
10993.1.2.1.4.1 Validate the presence and order of attribute groups
1100
1101 Client requests and IPP object responses contain attribute groups
1102 that Section 3 requires to be present and in a specified order. An
1103 IPP object verifies that the attribute groups are present and in the
1104 correct order in requests supplied by clients (attribute groups
1105 without an * in the following tables).
1106
1107 If an IPP object receives a request with (1) required attribute
1108 groups missing, or (2) the attributes groups are out of order, or (3)
1109 the groups are repeated, the IPP object REJECTS the request and
1110 RETURNS the 'client-error-bad-request' status code. For example, it
1111 is an error for the Job Template Attributes group to occur before the
1112 Operation Attributes group, for the Operation Attributes group to be
1113 omitted, or for an attribute group to occur more than once, except in
1114 the Get-Jobs response.
1115
1116 Since this kind of attribute group error is most likely to be an
1117 error detected by a client developer rather than by a customer, the
1118 IPP object NEED NOT return an indication of which attribute group was
1119
1120
1121
1122Hastings, et al. Informational [Page 20]
1123\f
1124RFC 3196 Internet Printing Protocol/1.1 November 2001
1125
1126
1127 in error in either the Unsupported Attributes group or the Status
1128 Message. Also, the IPP object NEED NOT find all attribute group
1129 errors before returning this error.
1130
11313.1.2.1.4.2 Ignore unknown attribute groups in the expected position
1132
1133 Future attribute groups may be added to the specification at the end
1134 of requests just before the Document Content and at the end of
1135 response, except for the Get-Jobs response, where it maybe there or
1136 before the first job attributes returned. If an IPP object receives
1137 an unknown attribute group in these positions, it ignores the entire
1138 group, rather than returning an error, since that group may be a new
1139 group in a later minor version of the protocol that can be ignored.
1140 (If the new attribute group cannot be ignored without confusing the
1141 client, the major version number would have been increased in the
1142 protocol document and in the request). If the unknown group occurs
1143 in a different position, the IPP object REJECTS the request and
1144 RETURNS the 'client-error-bad-request' status code.
1145
1146 Clients also ignore unknown attribute groups returned in a response.
1147
1148 Note: By validating that requests are in the proper form, IPP
1149 objects force clients to use the proper form which, in turn,
1150 increases the chances that customers will be able to use such clients
1151 from multiple vendors with IPP objects from other vendors.
1152
11533.1.2.1.4.3 Validate the presence of a single occurrence of required
1154 Operation attributes
1155
1156 Client requests and IPP object responses contain Operation attributes
1157 that [RFC2911] Section 3 requires to be present. Attributes within a
1158 group may be in any order, except for the ordering of target,
1159 charset, and natural languages attributes. These attributes MUST be
1160 first, and MUST be supplied in the following order: charset, natural
1161 language, and then target. An IPP object verifies that the
1162 attributes that Section 4 requires to be supplied by the client have
1163 been supplied in the request (attributes without an * in the
1164 following tables). An asterisk (*) indicates groups and Operation
1165 attributes that the client may omit in a request or an IPP object may
1166 omit in a response.
1167
1168 If an IPP object receives a request with required attributes missing
1169 or repeated from a group or in the wrong position, the behavior of
1170 the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
1171 implementations are:
1172
1173 REJECTS the request and RETURNS the 'client-error-bad-request'
1174 status code
1175
1176
1177
1178Hastings, et al. Informational [Page 21]
1179\f
1180RFC 3196 Internet Printing Protocol/1.1 November 2001
1181
1182
1183 accepts the request and uses the first occurrence of the attribute
1184 no matter where it is
1185
1186 accepts the request and uses the last occurrence of the attribute
1187 no matter where it is
1188
1189 accept the request and assume some default value for the missing
1190 attribute
1191
1192 Therefore, client MUST send conforming requests, if they want to
1193 receive the same behavior from all IPP object implementations. For
1194 example, it is an error for the "attributes-charset" or "attributes-
1195 natural-language" attribute to be omitted in any operation request,
1196 or for an Operation attribute to be supplied in a Job Template group
1197 or a Job Template attribute to be supplied in an Operation Attribute
1198 group in a create request. It is also an error to supply the
1199 "attributes-charset" attribute twice.
1200
1201 Since these kinds of attribute errors are most likely to be detected
1202 by a client developer rather than by a customer, the IPP object NEED
1203 NOT return an indication of which attribute was in error in either
1204 the Unsupported Attributes group or the Status Message. Also, the
1205 IPP object NEED NOT find all attribute errors before returning this
1206 error.
1207
1208 The following tables list all the attributes for all the operations
1209 by attribute group in each request and each response. The order of
1210 the groups is the order that the client supplies the groups as
1211 specified in [RFC2911] Section 3. The order of the attributes within
1212 a group is arbitrary, except as noted for some of the special
1213 operation attributes (charset, natural language, and target). The
1214 tables below use the following notation:
1215
1216 R indicates a REQUIRED attribute or operation that an IPP
1217 object MUST support
1218 O indicates an OPTIONAL attribute or operation that an IPP
1219 object NEED NOT support
1220 * indicates that a client MAY omit the attribute in a request
1221 and that an IPP object MAY omit the attribute in a response.
1222 The absence of an * means that a client MUST supply the
1223 attribute in a request and an IPP object MUST supply the
1224 attribute in a response.
1225 + indicates that this is not a IPP/1.0 operation, but is only
1226 a part of IPP/1.1 and future versions of IPP.
1227
1228
1229
1230
1231
1232
1233
1234Hastings, et al. Informational [Page 22]
1235\f
1236RFC 3196 Internet Printing Protocol/1.1 November 2001
1237
1238
1239 Operation Requests
1240
1241 The tables below show the attributes in their proper attribute groups
1242 for operation requests:
1243
1244 Note: All operation requests contain "version-number", "operation-
1245 id", and "request-id" parameters.
1246
1247 Print-Job Request (R):
1248 Group 1: Operation Attributes (R)
1249 attributes-charset (R)
1250 attributes-natural-language (R)
1251 printer-uri (R)
1252 requesting-user-name (R*)
1253 job-name (R*)
1254 ipp-attribute-fidelity (R*)
1255 document-name (R*)
1256 document-format (R*)
1257 document-natural-language (O*)
1258 compression (R*)
1259 job-k-octets (O*)
1260 job-impressions (O*)
1261 job-media-sheets (O*)
1262 Group 2: Job Template Attributes (R*)
1263 <Job Template attributes> (O*)
1264 (see [RFC2911] Section 4.2)
1265 Group 3: Document Content (R)
1266 <document content>
1267
1268 Validate-Job Request (R):
1269 Group 1: Operation Attributes (R)
1270 attributes-charset (R)
1271 attributes-natural-language (R)
1272 printer-uri (R)
1273 requesting-user-name (R*)
1274 job-name (R*)
1275 ipp-attribute-fidelity (R*)
1276 document-name (R*)
1277 document-format (R*)
1278 document-natural-language (O*)
1279 compression (R*)
1280 job-k-octets (O*)
1281 job-impressions (O*)
1282 job-media-sheets (O*)
1283 Group 2: Job Template Attributes (R*)
1284 <Job Template attributes> (O*)
1285 (see [RFC2911] Section 4.2)
1286
1287
1288
1289
1290Hastings, et al. Informational [Page 23]
1291\f
1292RFC 3196 Internet Printing Protocol/1.1 November 2001
1293
1294
1295 Print-URI Request (O):
1296 Group 1: Operation Attributes (R)
1297 attributes-charset (R)
1298 attributes-natural-language (R)
1299 printer-uri (R)
1300 document-uri (R)
1301 requesting-user-name (R*)
1302 job-name (R*)
1303 ipp-attribute-fidelity (R*)
1304 document-name (R*)
1305 document-format (R*)
1306 document-natural-language (O*)
1307 compression (R*)
1308 job-k-octets (O*)
1309 job-impressions (O*)
1310 job-media-sheets (O*)
1311 Group 2: Job Template Attributes (R*)
1312 <Job Template attributes> (O*) (see
1313 (see [RFC2911] Section 4.2)
1314
1315 Create-Job Request (O):
1316 Group 1: Operation Attributes (R)
1317 attributes-charset (R)
1318 attributes-natural-language (R)
1319 printer-uri (R)
1320 requesting-user-name (R*)
1321 job-name (R*)
1322 ipp-attribute-fidelity (R*)
1323 job-k-octets (O*)
1324 job-impressions (O*)
1325 job-media-sheets (O*)
1326 Group 2: Job Template Attributes (R*)
1327 <Job Template attributes> (O*) (see
1328 (see [RFC2911] Section 4.2)
1329
1330 Get-Printer-Attributes Request (R):
1331 Group 1: Operation Attributes (R)
1332 attributes-charset (R)
1333 attributes-natural-language (R)
1334 printer-uri (R)
1335 requesting-user-name (R*)
1336 requested-attributes (R*)
1337 document-format (R*)
1338
1339 Get-Jobs Request (R):
1340 Group 1: Operation Attributes (R)
1341 attributes-charset (R)
1342 attributes-natural-language (R)
1343
1344
1345
1346Hastings, et al. Informational [Page 24]
1347\f
1348RFC 3196 Internet Printing Protocol/1.1 November 2001
1349
1350
1351 printer-uri (R)
1352 requesting-user-name (R*)
1353 limit (R*)
1354 requested-attributes (R*)
1355 which-jobs (R*)
1356 my-jobs (R*)
1357
1358 Send-Document Request (O):
1359 Group 1: Operation Attributes (R)
1360 attributes-charset (R)
1361 attributes-natural-language (R)
1362 (printer-uri & job-id) | job-uri (R)
1363 last-document (R)
1364 requesting-user-name (R*)
1365 document-name (R*)
1366 document-format (R*)
1367 document-natural-language (O*)
1368 compression (R*)
1369 Group 2: Document Content (R*)
1370 <document content>
1371
1372 Send-URI Request (O):
1373 Group 1: Operation Attributes (R)
1374 attributes-charset (R)
1375 attributes-natural-language (R)
1376 (printer-uri & job-id) | job-uri (R)
1377 last-document (R)
1378 document-uri (R)
1379 requesting-user-name (R*)
1380 document-name (R*)
1381 document-format (R*)
1382 document-natural-language (O*)
1383 compression (R*)
1384
1385 Cancel-Job Request (R):
1386 Release-Job Request (O+):
1387 Group 1: Operation Attributes (R)
1388 attributes-charset (R)
1389 attributes-natural-language (R)
1390 (printer-uri & job-id) | job-uri (R)
1391 requesting-user-name (R*)
1392 message (O*)
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402Hastings, et al. Informational [Page 25]
1403\f
1404RFC 3196 Internet Printing Protocol/1.1 November 2001
1405
1406
1407 Get-Job-Attributes Request (R):
1408 Group 1: Operation Attributes (R)
1409 attributes-charset (R)
1410 attributes-natural-language (R)
1411 (printer-uri & job-id) | job-uri (R)
1412 requesting-user-name (R*)
1413 requested-attributes (R*)
1414
1415 Pause-Printer Request (O+):
1416 Resume-Printer Request (O+):
1417 Purge-Printer Request (O+):
1418 Group 1: Operation Attributes (R)
1419 attributes-charset (R)
1420 attributes-natural-language (R)
1421 printer-uri (R)
1422 requesting-user-name (R*)
1423
1424 Hold-Job Request (O+):
1425 Restart-Job Request (O+):
1426 Group 1: Operation Attributes (R)
1427 attributes-charset (R)
1428 attributes-natural-language (R)
1429 (printer-uri & job-id) | job-uri (R)
1430 requesting-user-name (R*)
1431 job-hold-until (R*)
1432 message (O*)
1433
1434 Operation Responses
1435
1436 The tables below show the response attributes in their proper
1437 attribute groups for responses.
1438
1439 Note: All operation responses contain "version-number", "status-
1440 code", and "request-id" parameters.
1441
1442 Print-Job Response (R):
1443 Create-Job Response (O):
1444 Send-Document Response (O):
1445 Group 1: Operation Attributes (R)
1446 attributes-charset (R)
1447 attributes-natural-language (R)
1448 status-message (O*)
1449 detailed-status-message (O*)
1450 Group 2: Unsupported Attributes (R*) (see Note 3)
1451 n <unsupported attributes> (R*)
1452 Group 3: Job Object Attributes(R*) (see Note 2)
1453 job-uri (R)
1454 job-id (R)
1455
1456
1457
1458Hastings, et al. Informational [Page 26]
1459\f
1460RFC 3196 Internet Printing Protocol/1.1 November 2001
1461
1462
1463 job-state (R)
1464 job-state-reasons (O* | R+)
1465 job-state-message (O*)
1466 number-of-intervening-jobs (O*)
1467
1468 Validate-Job Response (R):
1469 Cancel-Job Response (R):
1470 Hold-Job Response (O+):
1471 Release-Job Response (O+):
1472 Restart-Job Response (O+):
1473 Group 1: Operation Attributes (R)
1474 attributes-charset (R)
1475 attributes-natural-language (R)
1476 status-message (O*)
1477 detailed-status-message (O*)
1478 Group 2: Unsupported Attributes (R*) (see Note 3)
1479 <unsupported attributes> (R*)
1480
1481 Print-URI Response (O):
1482 Send-URI Response (O):
1483 Group 1: Operation Attributes (R)
1484 attributes-charset (R)
1485 attributes-natural-language (R)
1486 status-message (O*)
1487 detailed-status-message (O*)
1488 document-access-error (O*)
1489 Group 2: Unsupported Attributes (R*) (see Note 3)
1490 <unsupported attributes> (R*)
1491 Group 3: Job Object Attributes(R*) (see Note 2)
1492 job-uri (R)
1493 job-id (R)
1494 job-state (R)
1495 job-state-reasons (O* | R+)
1496 job-state-message (O*)
1497 number-of-intervening-jobs (O*)
1498
1499 Get-Printer-Attributes Response (R):
1500 Group 1: Operation Attributes (R)
1501 attributes-charset (R)
1502 attributes-natural-language (R)
1503 status-message (O*)
1504 detailed-status-message (O*)
1505 Group 2: Unsupported Attributes (R*) (see Note 4)
1506 <unsupported attributes> (R*)
1507 Group 3: Printer Object Attributes(R*) (see Note 2)
1508 <requested attributes> (R*)
1509
1510
1511
1512
1513
1514Hastings, et al. Informational [Page 27]
1515\f
1516RFC 3196 Internet Printing Protocol/1.1 November 2001
1517
1518
1519 Get-Jobs Response (R):
1520 Group 1: Operation Attributes (R)
1521 attributes-charset (R)
1522 attributes-natural-language (R)
1523 status-message (O*)
1524 detailed-status-message (O*)
1525 Group 2: Unsupported Attributes (R*) (see Note 4)
1526 <unsupported attributes> (R*)
1527 Group 3: Job Object Attributes(R*) (see Note 2, 5)
1528 <requested attributes> (R*)
1529
1530 Get-Job-Attributes Response (R):
1531 Group 1: Operation Attributes (R)
1532 attributes-charset (R)
1533 attributes-natural-language (R)
1534 status-message (O*)
1535 detailed-status-message (O*)
1536 Group 2: Unsupported Attributes (R*) (see Note 4)
1537 <unsupported attributes> (R*)
1538 Group 3: Job Object Attributes(R*) (see Note 2)
1539 <requested attributes> (R*)
1540
1541 Pause-Printer Response (O+):
1542 Resume-Printer Response (O+):
1543 Purge-Printer Response (O+):
1544 Group 1: Operation Attributes (R)
1545 attributes-charset (R)
1546 attributes-natural-language (R)
1547 status-message (O*)
1548 detailed-status-message (O*)
1549 Group 2: Unsupported Attributes (R*) (see Note 4)
1550 <unsupported attributes> (R*)
1551
1552 Note 2 - the Job Object Attributes and Printer Object Attributes are
1553 returned only if the IPP object returns one of the success status
1554 codes.
1555
1556 Note 3 - the Unsupported Attributes Group is present only if the
1557 client included some Operation and/or Job Template attributes or
1558 values that the Printer doesn't support whether a success or an error
1559 return.
1560
1561 Note 4 - the Unsupported Attributes Group is present only if the
1562 client included some Operation attributes that the Printer doesn't
1563 support whether a success or an error return.
1564
1565
1566
1567
1568
1569
1570Hastings, et al. Informational [Page 28]
1571\f
1572RFC 3196 Internet Printing Protocol/1.1 November 2001
1573
1574
1575 Note 5: for the Get-Jobs operation the response contains a separate
1576 Job Object Attributes group 3 to N containing requested-attributes
1577 for each job object in the response.
1578
15793.1.2.1.5 Validate the values of the REQUIRED Operation attributes
1580
1581 An IPP object validates the values supplied by the client of the
1582 REQUIRED Operation attribute that the IPP object MUST support. The
1583 next section specifies the validation of the values of the OPTIONAL
1584 Operation attributes that IPP objects MAY support.
1585
1586 The IPP object performs the following syntactic validation checks of
1587 each Operation attribute value:
1588
1589 a) that the length of each Operation attribute value is correct
1590 for the attribute syntax tag supplied by the client according
1591 to [RFC2911] Section 4.1,
1592
1593 b) that the attribute syntax tag is correct for that Operation
1594 attribute according to [RFC2911] Section 3,
1595
1596 c) that the value is in the range specified for that Operation
1597 attribute according to [RFC2911] Section 3,
1598
1599 d) that multiple values are supplied by the client only for
1600 operation attributes that are multi-valued, i.e., that are
1601 1setOf X according to [RFC2911] Section 3.
1602
1603 If any of these checks fail, the IPP object REJECTS the request and
1604 RETURNS the 'client-error-bad-request' or the 'client-error-request-
1605 value-too-long' status code. Since such an error is most likely to
1606 be an error detected by a client developer, rather than by an end-
1607 user, the IPP object NEED NOT return an indication of which attribute
1608 had the error in either the Unsupported Attributes Group or the
1609 Status Message. The description for each of these syntactic checks
1610 is explicitly expressed in the first IF statement in the following
1611 table.
1612
1613 In addition, the IPP object checks each Operation attribute value
1614 against some Printer object attribute or some hard-coded value if
1615 there is no "xxx-supported" Printer object attribute defined. If its
1616 value is not among those supported or is not in the range supported,
1617 then the IPP object REJECTS the request and RETURNS the error status
1618 code indicated in the table by the second IF statement. If the value
1619 of the Printer object's "xxx-supported" attribute is 'no-value'
1620 (because the system administrator hasn't configured a value), the
1621 check always fails.
1622
1623
1624
1625
1626Hastings, et al. Informational [Page 29]
1627\f
1628RFC 3196 Internet Printing Protocol/1.1 November 2001
1629
1630
1631 -----------------------------------------------
1632
1633 attributes-charset (charset)
1634
1635 IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
1636 error-bad-request'.
1637
1638 IF the value length is greater than 63 octets, REJECT/RETURN
1639 'client-error-request-value-too-long'.
1640
1641 IF NOT in the Printer object's "charset-supported" attribute,
1642 REJECT/RETURN "client-error-charset-not-supported".
1643
1644 attributes-natural-language(naturalLanguage)
1645
1646 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
1647 'client-error-bad-request'.
1648
1649 IF the value length is greater than 63 octets, REJECT/RETURN
1650 'client-error-request-value-too-long'.
1651
1652 ACCEPT the request even if not a member of the set in the Printer
1653 object's "generated-natural-language-supported" attribute. If the
1654 supplied value is not a member of the Printer object's
1655 "generated-natural-language-supported" attribute, use the Printer
1656 object's "natural-language- configured" value.
1657
1658 requesting-user-name
1659
1660 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1661 request'.
1662
1663 IF the value length is greater than 255 octets, REJECT/RETURN
1664 'client-error-request-value-too-long'.
1665
1666 IF the IPP object can obtain a better-authenticated name, use it
1667 instead.
1668
1669 job-name(name)
1670
1671 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1672 request'.
1673
1674 IF the value length is greater than 255 octets, REJECT/RETURN
1675 'client-error-request-value-too-long'.
1676
1677 IF NOT supplied by the client, the Printer object creates a name
1678 from the document-name or document-uri.
1679
1680
1681
1682Hastings, et al. Informational [Page 30]
1683\f
1684RFC 3196 Internet Printing Protocol/1.1 November 2001
1685
1686
1687 document-name (name)
1688
1689 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1690 request'.
1691
1692 IF the value length is greater than 255 octets, REJECT/RETURN
1693 'client-error-request-value-too-long'.
1694
1695 ipp-attribute-fidelity (boolean)
1696
1697 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1698 REJECT/RETURN 'client-error-bad-request'.
1699
1700 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1701 'client-error-request-value-too-long'
1702
1703 IF NOT supplied by the client, the IPP object assumes the value
1704 'false'.
1705
1706 document-format (mimeMediaType)
1707
1708 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
1709 'client-error-bad-request'.
1710
1711 IF the value length is greater than 255 octets, REJECT/RETURN
1712 'client-error-request-value-too-long'.
1713
1714 IF NOT in the Printer object's "document-format-supported"
1715 attribute, REJECT/RETURN 'client-error-document-format-not-
1716 supported'
1717
1718 IF NOT supplied by the client, the IPP object assumes the value of
1719 the Printer object's "document-format-default" attribute.
1720
1721 document-uri (uri)
1722
1723 IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
1724 error-bad-request'.
1725
1726 IF the value length is greater than 1023 octets, REJECT/RETURN
1727 'client-error-request-value-too-long'.
1728
1729 IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
1730 request'.
1731
1732 If the client-supplied URI scheme is not supported, i.e., the
1733 value is not in the Printer object's referenced-uri-scheme-
1734 supported" attribute, the Printer object MUST reject the request
1735
1736
1737
1738Hastings, et al. Informational [Page 31]
1739\f
1740RFC 3196 Internet Printing Protocol/1.1 November 2001
1741
1742
1743 and return the 'client-error-uri-scheme-not-supported' status
1744 code. The Printer object MAY check to see if the document exists
1745 and is accessible. If the document is not found or is not
1746 accessible, REJECT/RETURN 'client-error-not found'.
1747
1748 last-document (boolean)
1749
1750 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1751 REJECT/RETURN 'client-error-bad-request'.
1752
1753 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1754 'client-error-request-value-too-long'
1755
1756 job-id (integer(1:MAX))
1757
1758 IF NOT an single 'integer' value equal to 4 octets AND in the
1759 range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1760
1761 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
1762 error-not-found' or 'client-error-gone' status code, if keep track
1763 of recently deleted jobs.
1764
1765 requested-attributes (1setOf keyword)
1766
1767 IF NOT one or more 'keyword' values, REJECT/RETURN 'client-
1768 error-bad-request'.
1769
1770 IF the value length is greater than 255 octets, REJECT/RETURN
1771 'client-error-request-value-too-long'.
1772
1773 Ignore unsupported values, which are the keyword names of
1774 unsupported attributes. Don't bother to copy such requested
1775 (unsupported) attributes to the Unsupported Attribute response
1776 group since the response will not return them.
1777
1778 which-jobs (type2 keyword)
1779
1780 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1781 request'.
1782
1783 IF the value length is greater than 255 octets, REJECT/RETURN
1784 'client-error-request-value-too-long'.
1785
1786 IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
1787 the unsupported value to the Unsupported Attributes response group
1788 and REJECT/RETURN 'client-error-attributes-or-values-not-
1789 supported'.
1790
1791
1792
1793
1794Hastings, et al. Informational [Page 32]
1795\f
1796RFC 3196 Internet Printing Protocol/1.1 November 2001
1797
1798
1799 Note: a Printer still supports the 'completed' value even if it
1800 keeps no completed/canceled/aborted jobs: by returning no jobs
1801 when so queried.
1802
1803 IF NOT supplied by the client, the IPP object assumes the 'not-
1804 completed' value.
1805
1806 my-jobs (boolean)
1807
1808 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1809 REJECT/RETURN 'client-error-bad-request'.
1810
1811 IF the value length is NOT equal to 1 octet, REJECT/RETURN
1812 'client-error-request-value-too-long'
1813
1814 IF NOT supplied by the client, the IPP object assumes the 'false'
1815 value.
1816
1817 limit (integer(1:MAX))
1818
1819 IF NOT a single 'integer' value equal to 4 octets AND in the range
1820 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1821
1822 IF NOT supplied by the client, the IPP object returns all jobs, no
1823 matter how many.
1824
1825 -----------------------------------------------
1826
18273.1.2.1.6 Validate the values of the OPTIONAL Operation attributes
1828
1829 OPTIONAL Operation attributes are those that an IPP object MAY
1830 support. An IPP object validates the values of the OPTIONAL
1831 attributes supplied by the client. The IPP object performs the same
1832 syntactic validation checks for each OPTIONAL attribute value as in
1833 Section 3.1.2.1.5. As in Section 3.1.2.1.5, if any fail, the IPP
1834 object REJECTS the request and RETURNS the 'client-error-bad-request'
1835 or the 'client-error-request-value-too-long' status code.
1836
1837 In addition, the IPP object checks each Operation attribute value
1838 against some Printer attribute or some hard-coded value if there is
1839 no "xxx-supported" Printer attribute defined. If its value is not
1840 among those supported or is not in the range supported, then the IPP
1841 object REJECTS the request and RETURNS the error status code
1842 indicated in the table. If the value of the Printer object's "xxx-
1843 supported" attribute is 'no-value' (because the system administrator
1844 hasn't configured a value), the check always fails.
1845
1846
1847
1848
1849
1850Hastings, et al. Informational [Page 33]
1851\f
1852RFC 3196 Internet Printing Protocol/1.1 November 2001
1853
1854
1855 If the IPP object doesn't recognize/support an attribute, the IPP
1856 object treats the attribute as an unknown or unsupported attribute
1857 (see the last row in the table below).
1858
1859 -----------------------------------------------
1860
1861 document-natural-language (naturalLanguage)
1862
1863 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
1864 'client-error-bad-request'.
1865
1866 IF the value length is greater than 63 octets, REJECT/RETURN
1867 'client-error-request-value-too-long'.
1868
1869 IF NOT a value that the Printer object supports in document
1870 formats, (no corresponding "xxx-supported" Printer attribute),
1871 REJECT/RETURN 'client-error-natural-language-not-supported'.
1872
1873 compression (type3 keyword)
1874
1875 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1876 request'.
1877
1878 IF the value length is greater than 255 octets, REJECT/RETURN
1879 'client-error-request-value-too-long'.
1880
1881 IF NOT in the Printer object's "compression-supported" attribute,
1882 REJECT/RETURN 'client-error-compression-not-supported'.
1883
1884 Note to IPP/1.0 implementers: Support for the "compression"
1885 attribute was optional in IPP/1.0 and was changed to REQUIRED in
1886 IPP/1.1. However, an IPP/1.0 object SHOULD at least check for the
1887 "compression" attribute being present and reject the create
1888 request, if they don't support "compression". Not checking is a
1889 bug, since the data will be unintelligible.
1890
1891 job-k-octets (integer(0:MAX))
1892
1893 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1894 'client-error-bad-request'.
1895
1896 IF NOT in the range of the Printer object's "job-k-octets-
1897 supported" attribute, copy the attribute and the unsupported value
1898 to the Unsupported Attributes response group and REJECT/RETURN
1899 'client-error-attributes-or-values-not-supported'.
1900
1901
1902
1903
1904
1905
1906Hastings, et al. Informational [Page 34]
1907\f
1908RFC 3196 Internet Printing Protocol/1.1 November 2001
1909
1910
1911 job-impressions (integer(0:MAX))
1912
1913 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1914 'client-error-bad-request'.
1915
1916 IF NOT in the range of the Printer object's "job-impressions-
1917 supported" attribute, copy the attribute and the unsupported value
1918 to the Unsupported Attributes response group and REJECT/RETURN
1919 'client-error-attributes-or-values-not-supported'.
1920
1921 job-media-sheets (integer(0:MAX))
1922
1923 IF NOT a single 'integer' value equal to 4 octets, REJECT/RETURN
1924 'client-error-bad-request'.
1925
1926 IF NOT in the range of the Printer object's "job-media-sheets-
1927 supported" attribute, copy the attribute and the unsupported value
1928 to the Unsupported Attributes response group and REJECT/RETURN
1929 'client-error-attributes-or-values-not-supported'.
1930
1931 message (text(127))
1932
1933 IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
1934 request'.
1935
1936 IF the value length is greater than 127 octets, REJECT/RETURN
1937 'client-error-request-value-too-long'.
1938
1939 unknown or unsupported attribute
1940
1941 IF the attribute syntax supplied by the client is supported but
1942 the length is not legal for that attribute syntax, REJECT/RETURN
1943 'client-error-request-value-too-long'.
1944
1945 ELSE copy the attribute and value to the Unsupported Attributes
1946 response group and change the attribute value to the "out-of-band"
1947 'unsupported' value, but otherwise ignore the attribute.
1948
1949 Note: Future Operation attributes may be added to the protocol
1950 specification that may occur anywhere in the specified group. When
1951 the operation is otherwise successful, the IPP object returns the
1952 'successful-ok-ignored-or-substituted-attributes' status code.
1953 Ignoring unsupported Operation attributes in all operations is
1954 analogous to the handling of unsupported Job Template attributes in
1955 the create and Validate-Job operations when the client supplies the
1956 "ipp-attribute-fidelity" Operation attribute with the 'false' value.
1957 This last rule is so that we can add OPTIONAL Operation attributes to
1958 future versions of IPP so that older clients can inter-work with new
1959
1960
1961
1962Hastings, et al. Informational [Page 35]
1963\f
1964RFC 3196 Internet Printing Protocol/1.1 November 2001
1965
1966
1967 IPP objects and newer clients can inter-work with older IPP objects.
1968 (If the new attribute cannot be ignored without performing
1969 unexpectedly, the major version number would have been increased in
1970 the protocol document and in the request). This rule for Operation
1971 attributes is independent of the value of the "ipp-attribute-
1972 fidelity" attribute. For example, if an IPP object doesn't support
1973 the OPTIONAL "job-k-octets" attribute', the IPP object treats "job-
1974 k-octets" as an unknown attribute and only checks the length for the
1975 'integer' attribute syntax supplied by the client. If it is not four
1976 octets, the IPP object REJECTS the request and RETURNS the 'client-
1977 error-bad-request' status code, else the IPP object copies the
1978 attribute to the Unsupported Attribute response group, setting the
1979 value to the "out-of-band" 'unsupported' value, but otherwise ignores
1980 the attribute.
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018Hastings, et al. Informational [Page 36]
2019\f
2020RFC 3196 Internet Printing Protocol/1.1 November 2001
2021
2022
20233.1.2.2 Suggested Additional Processing Steps for Operations that
2024 Create/Validate Jobs and Add Documents
2025
2026 This section in combination with the previous section recommends the
2027 processing steps for the Print-Job, Validate-Job, Print-URI, Create-
2028 Job, Send-Document, and Send-URI operations that IPP objects SHOULD
2029 use. These are the operations that create jobs, validate a Print-Job
2030 request, and add documents to a job.
2031
2032 IIG Sect # Flow IPP error status codes
2033 ---------- ---- ----------------------
2034 |
2035 v No
2036 3.1.2.2.1 <ipp-attribute-fidelity> ------------------+
2037 <supplied?> |
2038 Yes| |
2039 | ipp-attribute-fidelity = no |
2040 |<------------------------------+
2041 v No
2042 3.1.2.2.2 <Printer is> --> server-error-not-accepting-jobs
2043 <accepting jobs?>
2044 Yes|
2045 v err
2046 3.1.2.3 <Validate values of> --> client-error-bad-request
2047 <Job template attributes> client-error-request-value-too-
2048 long
2049 <(length, tag, range,>
2050 <multi-value)>
2051 ok|
2052 v err
2053 3.1.2.3 <Validate values with> --> client-error-bad-request
2054 <supported values> client-error-attributes-or-
2055 | values-not-supported
2056 v err
2057 3.1.2.3.1 <Any conflicting> --> client-error-conflicting-
2058 attributes
2059 <Job Template attr values> client-error-attributes-or-
2060 values-not-supported
2061 v
2062
20633.1.2.2.1 Default "ipp-attribute-fidelity" if not supplied
2064
2065 The Printer object checks to see if the client supplied an "ipp-
2066 attribute-fidelity" Operation attribute. If the attribute is not
2067 supplied by the client, the IPP object assumes that the value is
2068 'false'.
2069
2070
2071
2072
2073
2074Hastings, et al. Informational [Page 37]
2075\f
2076RFC 3196 Internet Printing Protocol/1.1 November 2001
2077
2078
20793.1.2.2.2 Check that the Printer object is accepting jobs
2080
2081 If the value of the Printer objects "printer-is-accepting-jobs" is
2082 'false', the Printer object REJECTS the request and RETURNS the
2083 'server-error-not-accepting-jobs' status code.
2084
20853.1.2.2.3 Validate the values of the Job Template attributes
2086
2087 An IPP object validates the values of all Job Template attribute
2088 supplied by the client. The IPP object performs the analogous
2089 syntactic validation checks of each Job Template attribute value that
2090 it performs for Operation attributes (see Section 3.1.2.1.5.):
2091
2092 a) that the length of each value is correct for the attribute
2093 syntax tag supplied by the client according to [RFC2911]
2094 Section 4.1.
2095
2096 b) that the attribute syntax tag is correct for that attribute
2097 according to [RFC2911] Sections 4.2 to 4.4.
2098
2099 c) that multiple values are supplied only for multi-valued
2100 attributes, i.e., that are 1setOf X according to [RFC2911]
2101 Sections 4.2 to 4.4.
2102
2103 As in Section 3.1.2.1.5, if any of these syntactic checks fail, the
2104 IPP object REJECTS the request and RETURNS the 'client-error-bad-
2105 request' or 'client-error-request-value-too-long' status code as
2106 appropriate, independent of the value of the "ipp-attribute-
2107 fidelity". Since such an error is most likely to be an error
2108 detected by a client developer, rather than by an end-user, the IPP
2109 object NEED NOT return an indication of which attribute had the error
2110 in either the Unsupported Attributes Group or the Status Message.
2111 The description for each of these syntactic checks is explicitly
2112 expressed in the first IF statement in the following table.
2113
2114 Each Job Template attribute MUST occur no more than once. If an IPP
2115 Printer receives a create request with multiple occurrences of a Job
2116 Template attribute, it MAY:
2117
2118 1. reject the operation and return the 'client-error-bad-request'
2119 error status code
2120
2121 2. accept the operation and use the first occurrence of the
2122 attribute
2123
2124 3. accept the operation and use the last occurrence of the
2125 attribute
2126
2127
2128
2129
2130Hastings, et al. Informational [Page 38]
2131\f
2132RFC 3196 Internet Printing Protocol/1.1 November 2001
2133
2134
2135 depending on implementation. Therefore, clients MUST NOT supply
2136 multiple occurrences of the same Job Template attribute in the Job
2137 Attributes group in the request.
2138
21393.1.2.3 Algorithm for job validation
2140
2141 The process of validating a Job-Template attribute "xxx" against a
2142 Printer attribute "xxx-supported" can use the following validation
2143 algorithm (see section 3.2.1.2 in [RFC2911]).
2144
2145 To validate the value U of Job-Template attribute "xxx" against the
2146 value V of Printer "xxx-supported", perform the following algorithm:
2147
2148 1. If U is multi-valued, validate each value X of U by performing the
2149 algorithm in Table 7 with each value X. Each validation is
2150 separate from the standpoint of returning unsupported values.
2151 Example: If U is "finishings" that the client supplies with
2152 'staple', 'bind' values, then X takes on the successive values:
2153 'staple', then 'bind'
2154
2155 2. If V is multi-valued, validate X against each Z of V by performing
2156 the algorithm in Table 7 with each value Z. If a value Z
2157 validates, the validation for the attribute value X succeeds. If
2158 it fails, the algorithm is applied to the next value Z of V. If
2159 there are no more values Z of V, validation fails. Example" If V
2160 is "sides-supported" with values: 'one- sided', 'two-sided-long',
2161 and 'two-sided-short', then Z takes on the successive values:
2162 'one-sided', 'two-sided-long', and 'two-sided-short'. If the
2163 client supplies "sides" with 'two-sided- long', the first
2164 comparison fails ('one-sided' is not equal to 'two-sided-long'),
2165 the second comparison succeeds ('two-sided-long' is equal to
2166 'two-sided-long"), and the third comparison ('two-sided-short'
2167 with 'two-sided-long') is not even performed.
2168
2169 3. If both U and V are single-valued, let X be U and Z be V and use
2170 the validation rules in Table 7.
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186Hastings, et al. Informational [Page 39]
2187\f
2188RFC 3196 Internet Printing Protocol/1.1 November 2001
2189
2190
2191 Table 7 - Rules for validating single values X against Z
2192
2193 Attribute syntax attribute syntax validated if:
2194 of X of Z
2195
2196 integer rangeOfInteger X is within the range of Z
2197
2198 uri uriScheme the uri scheme in X is equal to
2199 Z
2200
2201 any boolean the value of Z is TRUE
2202
2203 any any X and Z are of the same type
2204 and are equal.
2205
2206 If the value of the Printer object's "xxx-supported" attribute is
2207 'no-value' (because the system administrator hasn't configured a
2208 value), the check always fails. If the check fails, the IPP object
2209 copies the attribute to the Unsupported Attributes response group
2210 with its unsupported value. If the attribute contains more than one
2211 value, each value is checked and each unsupported value is separately
2212 copied, while supported values are not copied. If an IPP object
2213 doesn't recognize/support a Job Template attribute, i.e., there is no
2214 corresponding Printer object "xxx-supported" attribute, the IPP
2215 object treats the attribute as an unknown or unsupported attribute
2216 (see the last row in the table below).
2217
2218 If some Job Template attributes are supported for some document
2219 formats and not for others or the values are different for different
2220 document formats, the IPP object SHOULD take that into account in
2221 this validation using the value of the "document-format" supplied by
2222 the client (or defaulted to the value of the Printer's "document-
2223 format-default" attribute, if not supplied by the client). For
2224 example, if "number-up" is supported for the 'text/plain' document
2225 format, but not for the 'application/postscript' document format, the
2226 check SHOULD (though it NEED NOT) depend on the value of the
2227 "document-format" operation attribute. See "document-format" in
2228 [RFC2911] section 3.2.1.1 and 3.2.5.1.
2229
2230 Note: whether the request is accepted or rejected is determined by
2231 the value of the "ipp-attribute-fidelity" attribute in a subsequent
2232 step, so that all Job Template attribute supplied are examined and
2233 all unsupported attributes and/or values are copied to the
2234 Unsupported Attributes response group.
2235
2236 -----------------------------------------------
2237
2238
2239
2240
2241
2242Hastings, et al. Informational [Page 40]
2243\f
2244RFC 3196 Internet Printing Protocol/1.1 November 2001
2245
2246
2247 job-priority (integer(1:100))
2248
2249 IF NOT a single 'integer' value with a length equal to 4 octets,
2250 REJECT/RETURN 'client-error-bad-request'.
2251
2252 IF NOT supplied by the client, use the value of the Printer
2253 object's "job-priority-default" attribute at job submission time.
2254
2255 IF NOT in the range 1 to 100, inclusive, copy the attribute and
2256 the unsupported value to the Unsupported Attributes response
2257 group.
2258
2259 Map the value to the nearest supported value in the range 1:100 as
2260 specified by the number of discrete values indicated by the value
2261 of the Printer's "job-priority-supported" attribute. See the
2262 formula in [RFC2911] Section 4.2.1.
2263
2264 job-hold-until (type3 keyword | name)
2265
2266 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2267 error-bad-request'.
2268
2269 IF the value length is greater than 255 octets, REJECT/RETURN
2270 'client-error-request-value-too-long'.
2271
2272 IF NOT supplied by the client, use the value of the Printer
2273 object's "job-hold-until" attribute at job submission time.
2274
2275 IF NOT in the Printer object's "job-hold-until-supported"
2276 attribute, copy the attribute and the unsupported value to the
2277 Unsupported Attributes response group.
2278
2279 job-sheets (type3 keyword | name)
2280
2281 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2282 error-bad-request'.
2283
2284 IF the value length is greater than 255 octets, REJECT/RETURN
2285 'client-error-request-value-too-long'.
2286
2287 IF NOT in the Printer object's "job-sheets-supported" attribute,
2288 copy the attribute and the unsupported value to the Unsupported
2289 Attributes response group.
2290
2291 multiple-document-handling (type2 keyword)
2292
2293 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
2294 request'.
2295
2296
2297
2298Hastings, et al. Informational [Page 41]
2299\f
2300RFC 3196 Internet Printing Protocol/1.1 November 2001
2301
2302
2303 IF the value length is greater than 255 octets, REJECT/RETURN
2304 'client-error-request-value-too-long'.
2305
2306 IF NOT in the Printer object's "multiple-document-handling-
2307 supported" attribute, copy the attribute and the unsupported value
2308 to the Unsupported Attributes response group.
2309
2310 copies (integer(1:MAX))
2311
2312 IF NOT a single 'integer' value with a length equal to 4 octets,
2313 REJECT/RETURN 'client-error-bad-request'.
2314
2315 IF NOT in range of the Printer object's "copies-supported"
2316 attribute
2317
2318 copy the attribute and the unsupported value to the Unsupported
2319 Attributes response group.
2320
2321 finishings (1setOf type2 enum)
2322
2323 IF NOT an 'enum' value(s) each with a length equal to 4 octets,
2324 REJECT/RETURN 'client-error-bad-request'.
2325
2326 IF NOT in the Printer object's "finishings-supported" attribute,
2327 copy the attribute and the unsupported value(s), but not any
2328 supported values, to the Unsupported Attributes response group.
2329
2330 page-ranges (1setOf rangeOfInteger(1:MAX))
2331
2332 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
2333 octets, REJECT/RETURN 'client-error-bad-request'.
2334
2335 IF first value is greater than second value in any range, the
2336 ranges are not in ascending order, or ranges overlap,
2337 REJECT/RETURN 'client-error-bad-request'.
2338
2339 IF the value of the Printer object's "page-ranges-supported"
2340 attribute is 'false', copy the attribute to the Unsupported
2341 Attributes response group and set the value to the "out-of-band"
2342 'unsupported' value.
2343
2344 sides (type2 keyword)
2345
2346 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
2347 request'.
2348
2349 IF the value length is greater than 255 octets, REJECT/RETURN
2350 'client-error-request-value-too-long'.
2351
2352
2353
2354Hastings, et al. Informational [Page 42]
2355\f
2356RFC 3196 Internet Printing Protocol/1.1 November 2001
2357
2358
2359 IF NOT in the Printer object's "sides-supported" attribute, copy
2360 the attribute and the unsupported value to the Unsupported
2361 Attributes response group.
2362
2363 number-up (integer(1:MAX))
2364
2365 IF NOT a single 'integer' value with a length equal to 4 octets,
2366 REJECT/RETURN 'client-error-bad-request'.
2367
2368 IF NOT a value or in the range of one of the values of the Printer
2369 object's "number-up-supported" attribute, copy the attribute and
2370 value to the Unsupported Attribute response group.
2371
2372 orientation-requested (type2 enum)
2373
2374 IF NOT a single 'enum' value with a length equal to 4 octets,
2375 REJECT/RETURN 'client-error-bad-request'.
2376
2377 IF NOT in the Printer object's "orientation-requested-supported"
2378 attribute, copy the attribute and the unsupported value to the
2379 Unsupported Attributes response group.
2380
2381 media (type3 keyword | name)
2382
2383 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
2384 error-bad-request'.
2385
2386 IF the value length is greater than 255 octets, REJECT/RETURN
2387 'client-error-request-value-too-long'.
2388
2389 IF NOT in the Printer object's "media-supported" attribute, copy
2390 the attribute and the unsupported value to the Unsupported
2391 Attributes response group.
2392
2393 printer-resolution (resolution)
2394
2395 IF NOT a single 'resolution' value with a length equal to 9
2396 octets, REJECT/RETURN 'client-error-bad-request'.
2397
2398 IF NOT in the Printer object's "printer-resolution-supported"
2399 attribute, copy the attribute and the unsupported value to the
2400 Unsupported Attributes response group.
2401
2402 print-quality (type2 enum)
2403
2404 IF NOT a single 'enum' value with a length equal to 4 octets,
2405 REJECT/RETURN 'client-error-bad-request'.
2406
2407
2408
2409
2410Hastings, et al. Informational [Page 43]
2411\f
2412RFC 3196 Internet Printing Protocol/1.1 November 2001
2413
2414
2415 IF NOT in the Printer object's "print-quality-supported"
2416 attribute, copy the attribute and the unsupported value to the
2417 Unsupported Attributes response group.
2418
2419 unknown or unsupported attribute (i.e., there is no corresponding
2420 Printer object "xxx-supported" attribute)
2421
2422 IF the attribute syntax supplied by the client is supported but
2423 the length is not legal for that attribute syntax,
2424
2425 REJECT/RETURN 'client-error-bad-request' if the length of the
2426 attribute syntax is fixed or 'client-error-request-value-too-long'
2427 if the length of the attribute syntax is variable.
2428
2429 ELSE copy the attribute and value to the Unsupported Attributes
2430 response group and change the attribute value to the "out-of-band"
2431 'unsupported' value. Any remaining Job Template Attributes are
2432 either unknown or unsupported Job Template attributes and are
2433 validated algorithmically according to their attribute syntax for
2434 proper length (see below).
2435
2436 -----------------------------------------------
2437
2438 If the attribute syntax is supported AND the length check fails,
2439 the IPP object REJECTS the request and RETURNS the 'client-error-
2440 bad-request' if the length of the attribute syntax is fixed or the
2441 'client-error-request-value-too-long' status code if the length of
2442 the attribute syntax is variable. Otherwise, the IPP object copies
2443 the unsupported Job Template attribute to the Unsupported
2444 Attributes response group and changes the attribute value to the
2445 "out-of-band" 'unsupported' value. The following table shows the
2446 length checks for all attribute syntaxes. In the following table:
2447 "<=" means less than or equal, "=" means equal to:
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466Hastings, et al. Informational [Page 44]
2467\f
2468RFC 3196 Internet Printing Protocol/1.1 November 2001
2469
2470
2471 Name Octet length check for read-write attributes
2472 ---------- ---------------------------------------------
2473
2474 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
2475 'textWithoutLanguage' <= 1023
2476 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
2477 'nameWithoutLanguage' <= 255
2478 'keyword' <= 255
2479 'enum' = 4
2480 'uri' <= 1023
2481 'uriScheme' <= 63
2482 'charset' <= 63
2483 'naturalLanguage' <= 63
2484 'mimeMediaType' <= 255
2485 'octetString' <= 1023
2486 'boolean' = 1
2487 'integer' = 4
2488 'rangeOfInteger' = 8
2489 'dateTime' = 11
2490 'resolution' = 9
2491 '1setOf X'
2492
2493 Note: It's possible for a Printer to receive a zero length keyword
2494 in a request. Since this is a keyword, its value needs to be
2495 compared with the supported values. Assuming that the printer
2496 doesn't have any values in its corresponding "xxx-supported"
2497 attribute that are keywords of zero length, the comparison will fail.
2498 Then the request will be accepted or rejected depending on the value
2499 of "ipp-attributes-fidelity" being 'false' or 'true', respectively.
2500 No special handling is required for
2501
25023.1.2.3.1 Check for conflicting Job Template attributes values
2503
2504 Once all the Operation and Job Template attributes have been checked
2505 individually, the Printer object SHOULD check for any conflicting
2506 values among all the supported values supplied by the client. For
2507 example, a Printer object might be able to staple and to print on
2508 transparencies, however due to physical stapling constraints, the
2509 Printer object might not be able to staple transparencies. The IPP
2510 object copies the supported attributes and their conflicting
2511 attribute values to the Unsupported Attributes response group. The
2512 Printer object only copies over those attributes that the Printer
2513 object either ignores or substitutes in order to resolve the
2514 conflict, and it returns the original values which were supplied by
2515 the client. For example suppose the client supplies "finishings"
2516 equals 'staple' and "media" equals 'transparency', but the Printer
2517 object does not support stapling transparencies. If the Printer
2518 chooses to ignore the stapling request in order to resolve the
2519
2520
2521
2522Hastings, et al. Informational [Page 45]
2523\f
2524RFC 3196 Internet Printing Protocol/1.1 November 2001
2525
2526
2527 conflict, the Printer objects returns "finishings" equal to 'staple'
2528 in the Unsupported Attributes response group. If any attributes are
2529 multi-valued, only the conflicting values of the attributes are
2530 copied.
2531
2532 Note: The decisions made to resolve the conflict (if there is a
2533 choice) is implementation dependent.
2534
25353.1.2.3.2 Decide whether to REJECT the request
2536
2537 If there were any unsupported Job Template attributes or
2538 unsupported/conflicting Job Template attribute values and the client
2539 supplied the "ipp-attribute-fidelity" attribute with the 'true'
2540 value, the Printer object REJECTS the request and return the status
2541 code:
2542
2543 1.'client-error-conflicting-attributes' status code, if there were
2544 any conflicts between attributes supplied by the client.
2545
2546 2.'client-error-attributes-or-values-not-supported' status code,
2547 otherwise.
2548
2549 Note: Unsupported Operation attributes or values that are returned
2550 do not affect the status returned in this step. If the unsupported
2551 Operation attribute was a serious error, the above already rejected
2552 the request in a previous step. If control gets to this step with
2553 unsupported Operation attributes being returned, they are not serious
2554 errors.
2555
2556 In general, the final results of Job processing are unknown at Job
2557 submission time. The client has to rely on notifications or polling
2558 to find out what happens at Job processing time. However, there are
2559 cases in which some Printers can determine at Job submission time
2560 that Job processing is going to fail. As an optimization, we'd like
2561 to have the Printer reject the Job in these cases.
2562
2563 There are three types of "processing" errors that might be detectable
2564 at Job submission time:
2565
2566 1. 'client-error-document-format-not-supported' : For the Print-
2567 Job, Send-Document, Print-URI, and Send-URI operations, if all these
2568 conditions are true:
2569
2570 - the Printer supports auto-sensing,
2571 - the request "document-format" operation attribute is
2572 'application/octet-stream',
2573 - the Printer receives document data before responding,
2574 - the Printer auto-senses the document format before responding,
2575
2576
2577
2578Hastings, et al. Informational [Page 46]
2579\f
2580RFC 3196 Internet Printing Protocol/1.1 November 2001
2581
2582
2583 - the sensed document format is not supported by the Printer
2584
2585 then the Printer should respond with 'client-error-document-format-
2586 not-supported' status.
2587
2588 2. 'client-error-compression-error': For the Print-Job, Send-
2589 Document, Print-URI, and Send-URI operations, if all these
2590 conditions are true:
2591
2592 - the client supplies a supported value for the "compression"
2593 operation attribute in the request
2594 - the Printer receives document data before responding,
2595 - the Printer attempts to decompress the document data before
2596 responding,
2597 - the document data cannot be decompressed using the algorithm
2598 specified by the "compression" operation attribute
2599
2600 then the Printer should respond with 'client-error-compression-error'
2601 status.
2602
2603 3. 'client-error-document-access-error': For the Print-URI, and
2604 Send-URI operations, if the Printer attempts and fails to pull the
2605 referenced document data before responding, it should respond with
2606 'client-error-document-access-error' status.
2607
2608 Some Printers are not able to detect these errors until Job
2609 processing time. In that case, the errors are recorded in the
2610 corresponding job-state and job-state reason attributes. (There is
2611 no standard way for a client to determine whether a Printer can
2612 detect these errors at Job submission time.) For example, if auto-
2613 sensing happens AFTER the job is accepted (as opposed to auto-sensing
2614 at submit time before returning the response), the implementation
2615 aborts the job, puts the job in the 'aborted' state and sets the
2616 'unsupported-document-format' value in the job's "job-state-reasons".
2617
2618 A client should always provide a valid "document-format" operation
2619 attribute whenever practical. In the absence of other information, a
2620 client itself may sniff the document data to determine document
2621 format.
2622
2623 Auto sensing at Job submission time may be more difficult for the
2624 Printer when combined with compression. For auto-sensed Jobs, a
2625 client may be better off deferring compression to the transfer
2626 protocol layer, e.g.; by using the HTTP Content-Encoding header.
2627
2628
2629
2630
2631
2632
2633
2634Hastings, et al. Informational [Page 47]
2635\f
2636RFC 3196 Internet Printing Protocol/1.1 November 2001
2637
2638
26393.1.2.3.3 For the Validate-Job operation, RETURN one of the success
2640 status codes
2641
2642 If the requested operation is the Validate-Job operation, the Printer
2643 object returns:
2644
2645 1. the "successful-ok" status code, if there are no unsupported or
2646 conflicting Job Template attributes or values.
2647 2. the "successful-ok-conflicting-attributes, if there are any
2648 conflicting Job Template attribute or values.
2649 3. the "successful-ok-ignored-or-substituted-attributes, if there
2650 are only unsupported Job Template attributes or values.
2651
2652 Note: Unsupported Operation attributes or values that are returned
2653 do not affect the status returned in this step. If the unsupported
2654 Operation attribute was a serious error, the above already rejected
2655 the request in a previous step. If control gets to this step with
2656 unsupported Operation attributes being returned, they are not serious
2657 errors.
2658
26593.1.2.3.4 Create the Job object with attributes to support
2660
2661 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
2662 by the client), the Printer object:
2663
2664 1. creates a Job object, assigns a unique value to the job's
2665 "job-uri" and "job-id" attributes, and initializes all of the
2666 job's other supported Job Description attributes.
2667 2. removes all unsupported attributes from the Job object.
2668 3. for each unsupported value, removes either the unsupported
2669 value or substitutes the unsupported attribute value with some
2670 supported value. If an attribute has no values after removing
2671 unsupported values from it, the attribute is removed from the
2672 Job object (so that the normal default behavior at job
2673 processing time will take place for that attribute).
2674 4. for each conflicting value, removes either the conflicting
2675 value or substitutes the conflicting attribute value with some
2676 other supported value. If an attribute has no values after
2677 removing conflicting values from it, the attribute is removed
2678 from the Job object (so that the normal default behavior at job
2679 processing time will take place for that attribute).
2680
2681 If there were no attributes or values flagged as unsupported, or the
2682 value of 'ipp-attribute-fidelity" was 'false', the Printer object is
2683 able to accept the create request and create a new Job object. If
2684 the "ipp-attribute-fidelity" attribute is set to 'true', the Job
2685 Template attributes that populate the new Job object are necessarily
2686 all the Job Template attributes supplied in the create request. If
2687
2688
2689
2690Hastings, et al. Informational [Page 48]
2691\f
2692RFC 3196 Internet Printing Protocol/1.1 November 2001
2693
2694
2695 the "ipp-attribute-fidelity" attribute is set to 'false', the Job
2696 Template attributes that populate the new Job object are all the
2697 client supplied Job Template attributes that are supported or that
2698 have value substitution. Thus, some of the requested Job Template
2699 attributes will not appear in the Job object because the Printer
2700 object did not support those attributes. The attributes that
2701 populate the Job object are persistently stored with the Job object
2702 for that Job. A Get-Job-Attributes operation on that Job object will
2703 return only those attributes that are persistently stored with the
2704 Job object.
2705
2706 Note: All Job Template attributes that are persistently stored with
2707 the Job object are intended to be "override values"; that is, they
2708 that take precedence over whatever other embedded instructions might
2709 be in the document data itself. However, it is not possible for all
2710 Printer objects to realize the semantics of "override". End users
2711 may query the Printer's "pdl-override-supported" attribute to
2712 determine if the Printer either attempts or does not attempt to
2713 override document data instructions with IPP attributes.
2714
2715 There are some cases, where a Printer supports a Job Template
2716 attribute and has an associated default value set for that attribute.
2717 In the case where a client does not supply the corresponding
2718 attribute, the Printer does not use its default values to populate
2719 Job attributes when creating the new Job object; only Job Template
2720 attributes actually in the create request are used to populate the
2721 Job object. The Printer's default values are only used later at Job
2722 processing time if no other IPP attribute or instruction embedded in
2723 the document data is present.
2724
2725 Note: If the default values associated with Job Template attributes
2726 that the client did not supply were to be used to populate the Job
2727 object, then these values would become "override values" rather than
2728 defaults. If the Printer supports the 'attempted' value of the
2729 "pdl-override-supported" attribute, then these override values could
2730 replace values specified within the document data. This is not the
2731 intent of the default value mechanism. A default value for an
2732 attribute is used only if the create request did not specify that
2733 attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
2734 being 'false') and no value was provided within the content of the
2735 document data.
2736
2737 If the client does not supply a value for some Job Template
2738 attribute, and the Printer does not support that attribute, as far as
2739 IPP is concerned, the result of processing that Job (with respect to
2740 the missing attribute) is undefined.
2741
2742
2743
2744
2745
2746Hastings, et al. Informational [Page 49]
2747\f
2748RFC 3196 Internet Printing Protocol/1.1 November 2001
2749
2750
27513.1.2.3.5 Return one of the success status codes
2752
2753 Once the Job object has been created, the Printer object accepts the
2754 request and returns to the client:
2755
2756 1. the 'successful-ok' status code, if there are no unsupported or
2757 conflicting Job Template attributes or values.
2758 2. the 'successful-ok-conflicting-attributes' status code, if
2759 there are any conflicting Job Template attribute or values.
2760 3. the 'successful-ok-ignored-or-substituted-attributes' status
2761 code, if there are only unsupported Job Template attributes or
2762 values.
2763
2764 Note: Unsupported Operation attributes or values that are returned
2765 do not affect the status returned in this step. If the unsupported
2766 Operation attribute was a serious error, the above already rejected
2767 the request in a previous step. If control gets to this step with
2768 unsupported Operation attributes being returned, they are not serious
2769 errors.
2770
2771 The Printer object also returns Job status attributes that indicate
2772 the initial state of the Job ('pending', 'pending-held',
2773 'processing', etc.), etc. See Print-Job Response, [RFC2911] section
2774 3.2.1.2.
2775
27763.1.2.3.6 Accept appended Document Content
2777
2778 The Printer object accepts the appended Document Content data and
2779 either starts it printing, or spools it for later processing.
2780
27813.1.2.3.7 Scheduling and Starting to Process the Job
2782
2783 The Printer object uses its own configuration and implementation
2784 specific algorithms for scheduling the Job in the correct processing
2785 order. Once the Printer object begins processing the Job, the
2786 Printer changes the Job's state to 'processing'. If the Printer
2787 object supports PDL override (the "pdl-override-supported" attribute
2788 set to 'attempted'), the implementation does its best to see that IPP
2789 attributes take precedence over embedded instructions in the document
2790 data.
2791
27923.1.2.3.8 Completing the Job
2793
2794 The Printer object continues to process the Job until it can move the
2795 Job into the 'completed' state. If an Cancel-Job operation is
2796 received, the implementation eventually moves the Job into the
2797 'canceled' state. If the system encounters errors during processing
2798 that do not allow it to progress the Job into a completed state, the
2799
2800
2801
2802Hastings, et al. Informational [Page 50]
2803\f
2804RFC 3196 Internet Printing Protocol/1.1 November 2001
2805
2806
2807 implementation halts all processing, cleans up any resources, and
2808 moves the Job into the 'aborted' state.
2809
28103.1.2.3.9 Destroying the Job after completion
2811
2812 Once the Job moves to the 'completed', 'aborted', or 'canceled'
2813 state, it is an implementation decision as to when to destroy the Job
2814 object and release all associated resources. Once the Job has been
2815 destroyed, the Printer would return either the "client-error-not-
2816 found" or "client-error-gone" status codes for operations directed at
2817 that Job.
2818
2819 Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
2820 value for a sufficiently long time after a job has been destroyed, so
2821 that stale references kept by clients are less likely to access the
2822 wrong (newer) job.
2823
28243.1.2.3.10 Interaction with "ipp-attribute-fidelity"
2825
2826 Some Printer object implementations may support "ipp-attribute-
2827 fidelity" set to 'true' and "pdl-override-supported" set to
2828 'attempted' and yet still not be able to realize exactly what the
2829 client specifies in the create request. This is due to legacy
2830 decisions and assumptions that have been made about the role of job
2831 instructions embedded within the document data and external job
2832 instructions that accompany the document data and how to handle
2833 conflicts between such instructions. The inability to be 100%
2834 precise about how a given implementation will behave is also
2835 compounded by the fact that the two special attributes, "ipp-
2836 attribute-fidelity" and "pdl-"override-supported", apply to the whole
2837 job rather than specific values for each attribute. For example, some
2838 implementations may be able to override almost all Job Template
2839 attributes except for "number-up". Character Sets, natural
2840 languages, and internationalization
2841
2842 This section discusses character set support, natural language
2843 support and internationalization.
2844
28453.1.2.3.11 Character set code conversion support
2846
2847 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
2848 support additional charsets. It is RECOMMENDED that an IPP object
2849 also support US-ASCII, since many clients support US-ASCII, and
2850 indicate that UTF-8 and US-ASCII are supported by populating the
2851 Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
2852 IPP object is required to code covert with as little loss as possible
2853 between the charsets that it supports, as indicated in the Printer's
2854 "charsets-supported" attribute.
2855
2856
2857
2858Hastings, et al. Informational [Page 51]
2859\f
2860RFC 3196 Internet Printing Protocol/1.1 November 2001
2861
2862
2863 How should the server handle the situation where the "attributes-
2864 charset" of the response itself is "us-ascii", but one or more
2865 attributes in that response is in the "utf-8" format?
2866
2867 Example: Consider a case where a client sends a Print-Job request
2868 with "utf-8" as the value of "attributes-charset" and with the "job-
2869 name" attribute supplied. Later another client submits a Get-Job-
2870 Attribute or Get-Jobs request. This second request contains the
2871 "attributes-charset" with value "us-ascii" and "requested-attributes"
2872 attribute with exactly one value "job-name".
2873
2874 According to the RFC2911 document (section 3.1.4.2), the value of the
2875 "attributes-charset" for the response of the second request must be
2876 "us-ascii" since that is the charset specified in the request. The
2877 "job-name" value, however, is in "utf-8" format. Should the request
2878 be rejected even though both "utf-8" and "us-ascii" charsets are
2879 supported by the server? or should the "job-name" value be converted
2880 to "us-ascii" and return "successful-ok-conflicting-attributes"
2881 (0x0002) as the status code?
2882
2883 Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
2884 ascii, the second paragraph of section 3.1.4.2 applies so that the
2885 IPP object MUST accept the request, perform code set conversion
2886 between these two charsets with "the highest fidelity possible" and
2887 return 'successful-ok', rather than a warning 'successful-ok-
2888 conflicting-attributes, or an error. The printer will do the best it
2889 can to convert between each of the character sets that it supports --
2890 even if that means providing a string of question marks because none
2891 of the characters are representable in US ASCII. If it can't perform
2892 such conversion, it MUST NOT advertise us-ascii as a value of its
2893 "attributes-charset-supported" and MUST reject any request that
2894 requests 'us-ascii'.
2895
2896 One IPP object implementation strategy is to convert all request text
2897 and name values to a Unicode internal representation. This is 16-bit
2898 and virtually universal. Then convert to the specified operation
2899 attributes-charset on output.
2900
2901 Also it would be smarter for a client to ask for 'utf-8', rather than
2902 'us-ascii' and throw away characters that it doesn't understand,
2903 rather than depending on the code conversion of the IPP object.
2904
29053.1.2.3.12 What charset to return when an unsupported charset is
2906 requested (Issue 1.19)?
2907
2908 Section 3.1.4.1 Request Operation attributes was clarified in
2909 November 1998 as follows:
2910
2911
2912
2913
2914Hastings, et al. Informational [Page 52]
2915\f
2916RFC 3196 Internet Printing Protocol/1.1 November 2001
2917
2918
2919 All clients and IPP objects MUST support the 'utf-8' charset
2920 [RFC2044] and MAY support additional charsets provided that they are
2921 registered with IANA [IANA-CS]. If the Printer object does not
2922 support the client supplied charset value, the Printer object MUST
2923 reject the request, set the "attributes-charset" to 'utf-8' in the
2924 response, and return the 'client-error-charset-not-supported' status
2925 code and any 'text' or 'name' attributes using the 'utf-8' charset.
2926
2927 Since the client and IPP object MUST support UTF-8, returning any
2928 text or name attributes in UTF-8 when the client requests a charset
2929 that is not supported should allow the client to display the text or
2930 name.
2931
2932 Since such an error is a client error, rather than a user error, the
2933 client should check the status code first so that it can avoid
2934 displaying any other returned 'text' and 'name' attributes that are
2935 not in the charset requested.
2936
2937 Furthermore, [RFC2911] section 14.1.4.14 client-error-charset-not-
2938 supported (0x040D) was clarified in November 1998 as follows:
2939
2940 For any operation, if the IPP Printer does not support the charset
2941 supplied by the client in the "attributes-charset" operation
2942 attribute, the Printer MUST reject the operation and return this
2943 status and any 'text' or 'name' attributes using the 'utf-8' charset
2944 (see Section 3.1.4.1).
2945
29463.1.2.3.13 Natural Language Override (NLO)
2947
2948 The 'text' and 'name' attributes each have two forms. One has an
2949 implicit natural language, and the other has an explicit natural
2950 language. The 'textWithoutLanguage' and 'textWithLanguage' are the
2951 two 'text' forms. The 'nameWithoutLanguage" and 'nameWithLanguage
2952 are the two 'name' forms. If a receiver (IPP object or IPP client)
2953 supports an attribute with attribute syntax 'text', it MUST support
2954 both forms in a request and a response. A sender (IPP client or IPP
2955 object) MAY send either form for any such attribute. When a sender
2956 sends a WithoutLanguage form, the implicit natural language is
2957 specified in the "attributes-natural-language" operation attribute,
2958 which all senders MUST include in every request and response.
2959
2960 When a sender sends a WithLanguage form, it MAY be different from the
2961 implicit natural language supplied by the sender or it MAY be the
2962 same. The receiver MUST treat either form equivalently.
2963
2964 There is an implementation decision for senders, whether to always
2965 send the WithLanguage forms or use the WithoutLanguage form when the
2966 attribute's natural language is the same as the request or response.
2967
2968
2969
2970Hastings, et al. Informational [Page 53]
2971\f
2972RFC 3196 Internet Printing Protocol/1.1 November 2001
2973
2974
2975 The former approach makes the sender implementation simpler. The
2976 latter approach is more efficient on the wire and allows inter-
2977 working with non-conforming receivers that fail to support the
2978 WithLanguage forms. As each approach have advantages, the choice is
2979 completely up to the implementer of the sender.
2980
2981 Furthermore, when a client receives a 'text' or 'name' job attribute
2982 that it had previously supplied, that client MUST NOT expect to see
2983 the attribute in the same form, i.e., in the same WithoutLanguage or
2984 WithLanguage form as the client supplied when it created the job.
2985 The IPP object is free to transform the attribute from the
2986 WithLanguage form to the WithoutLanguage form and vice versa, as long
2987 as the natural language is preserved. However, in order to meet this
2988 latter requirement, it is usually simpler for the IPP object
2989 implementation to store the natural language explicitly with the
2990 attribute value, i.e., to store using an internal representation that
2991 resembles the WithLanguage form.
2992
2993 The IPP Printer MUST copy the natural language of a job, i.e., the
2994 value of the "attributes-natural-language" operation attribute
2995 supplied by the client in the create operation, to the Job object as
2996 a Job Description attribute, so that a client is able to query it.
2997 In returning a Get-Job-Attributes response, the IPP object MAY return
2998 one of three natural language values in the responses "attributes-
2999 natural-language" operation attribute: (1) that requested by the
3000 requester, (2) the natural language of the job, or (3) the configured
3001 natural language of the IPP Printer, if the requested language is not
3002 supported by the IPP Printer.
3003
3004 This "attributes-natural-language" Job Description attribute is
3005 useful for an IPP object implementation that prints start sheets in
3006 the language of the user who submitted the job. This same Job
3007 Description attribute is useful to a multi-lingual operator who has
3008 to communicate with different job submitters in different natural
3009 languages. This same Job Description attribute is expected to be
3010 used in the future to generate notification messages in the natural
3011 language of the job submitter.
3012
3013 Early drafts of [RFC2911] contained a job-level natural language
3014 override (NLO) for the Get-Jobs response. A job-level (NLO) is an
3015 (unrequested) Job Attribute which then specified the implicit natural
3016 language for any other WithoutLanguage job attributes returned in the
3017 response for that job. Interoperability testing of early
3018 implementations showed that no one was implementing the job-level NLO
3019 in Get-Job responses. So the job-level NLO was eliminated from the
3020 Get-Jobs response. This simplification makes all requests and
3021 responses consistent in that the implicit natural language for any
3022
3023
3024
3025
3026Hastings, et al. Informational [Page 54]
3027\f
3028RFC 3196 Internet Printing Protocol/1.1 November 2001
3029
3030
3031 WithoutLanguage 'text' or 'name' form is always supplied in the
3032 request's or response's "attributes-natural-language" operation
3033 attribute.
3034
30353.1.3 Status codes returned by operation
3036
3037 This section corresponds to [RFC2911] section 3.1.6 "Operation
3038 Response Status Codes and Status Messages". This section lists all
3039 status codes once in the first operation (Print-Job). Then it lists
3040 the status codes that are different or specialized for subsequent
3041 operations under each operation.
3042
30433.1.3.1 Printer Operations
3044
30453.1.3.1.1 Print-Job
3046
3047 The Printer object MUST return one of the following "status-code"
3048 values for the indicated reason. Whether all of the document data
3049 has been accepted or not before returning the success or error
3050 response depends on implementation. See Section 13 in [RFC2911] for
3051 a more complete description of each status code.
3052
3053 For the following success status codes, the Job object has been
3054 created and the "job-id", and "job-uri" assigned and returned in the
3055 response:
3056
3057 successful-ok: no request attributes were substituted or ignored.
3058
3059 successful-ok-ignored-or-substituted-attributes: some supplied
3060 (1) attributes were ignored or (2) unsupported attribute syntaxes
3061 or values were substituted with supported values or were ignored.
3062 Unsupported attributes, attribute syntax's, or values MUST be
3063 returned in the Unsupported Attributes group of the response.
3064
3065 successful-ok-conflicting-attributes: some supplied attribute
3066 values conflicted with the values of other supplied attributes and
3067 were either substituted or ignored. Attributes or values which
3068 conflict with other attributes and have been substituted or
3069 ignored MUST be returned in the Unsupported Attributes group of
3070 the response as supplied by the client.
3071
3072 [RFC2911] section 3.1.6 Operation Status Codes and Messages states:
3073
3074 If the Printer object supports the "status-message" operation
3075 attribute, it SHOULD use the REQUIRED 'utf-8' charset to return a
3076 status message for the following error status codes (see section
3077 13 in [RFC2911]): 'client-error-bad-request', 'client-error-
3078 charset-not-supported', 'server-error-internal-error', 'server-
3079
3080
3081
3082Hastings, et al. Informational [Page 55]
3083\f
3084RFC 3196 Internet Printing Protocol/1.1 November 2001
3085
3086
3087 error-operation-not-supported', and 'server-error-version-not-
3088 supported'. In this case, it MUST set the value of the
3089 "attributes-charset" operation attribute to 'utf-8' in the error
3090 response.
3091
3092 For the following error status codes, no job is created and no
3093 "job-id" or "job-uri" is returned:
3094
3095 client-error-bad-request: The request syntax does not conform
3096 to the specification.
3097
3098 client-error-forbidden: The request is being refused for
3099 authorization or authentication reasons. The implementation
3100 security policy is to not reveal whether the failure is one of
3101 authentication or authorization.
3102
3103 client-error-not-authenticated: Either the request requires
3104 authentication information to be supplied or the authentication
3105 information is not sufficient for authorization.
3106
3107 client-error-not-authorized: The requester is not authorized
3108 to perform the request on the target object.
3109
3110 client-error-not-possible: The request cannot be carried out
3111 because of the state of the system. See also 'server-error-
3112 not-accepting-jobs' status code, which MUST take precedence if
3113 the Printer object's "printer-accepting-jobs" attribute is
3114 'false'.
3115
3116 client-error-timeout: not applicable.
3117
3118 client-error-not-found: the target object does not exist.
3119
3120 client-error-gone: the target object no longer exists and no
3121 forwarding address is known.
3122
3123 client-error-request-entity-too-large: the size of the request
3124 and/or print data exceeds the capacity of the IPP Printer to
3125 process it.
3126
3127 client-error-request-value-too-long: the size of request
3128 variable length attribute values, such as 'text' and 'name'
3129 attribute syntax's, exceed the maximum length specified in
3130 [RFC2911] for the attribute and MUST be returned in the
3131 Unsupported Attributes Group.
3132
3133
3134
3135
3136
3137
3138Hastings, et al. Informational [Page 56]
3139\f
3140RFC 3196 Internet Printing Protocol/1.1 November 2001
3141
3142
3143 supplied is not supported. The "document-format" attribute
3144 with the unsupported value MUST be returned in the Unsupported
3145 Attributes Group. This error SHOULD take precedence over any
3146 other 'xxx-not-supported' error, except 'client-error-charset-
3147 not-supported'.
3148
3149 client-error-attributes-or-values-not-supported: one or more
3150 supplied attributes, attribute syntax's, or values are not
3151 supported and the client supplied the "ipp-attributes-
3152 fidelity" operation attribute with a 'true' value. They MUST
3153 be returned in the Unsupported Attributes Group as explained
3154 below.
3155
3156 client-error-uri-scheme-not-supported: not applicable.
3157
3158 client-error-charset-not-supported: the charset supplied in
3159 the "attributes-charset" operation attribute is not supported.
3160 The Printer's "configured-charset" MUST be returned in the
3161 response as the value of the "attributes-charset" operation
3162 attribute and used for any 'text' and 'name' attributes
3163 returned in the error response. This error SHOULD take
3164 precedence over any other error, unless the request syntax is
3165 so bad that the client's supplied "attributes-charset" cannot
3166 be determined.
3167
3168 client-error-conflicting-attributes: one or more supplied
3169 attribute values conflicted with each other and the client
3170 supplied the "ipp-attributes-fidelity" operation attribute with
3171 a 'true' value. They MUST be returned in the Unsupported
3172 Attributes Group as explained below.
3173
3174 server-error-internal-error: an unexpected condition prevents
3175 the request from being fulfilled.
3176
3177 server-error-operation-not-supported: not applicable (since
3178 Print-Job is REQUIRED).
3179
3180 server-error-service-unavailable: the service is temporarily
3181 overloaded.
3182
3183 server-error-version-not-supported: the version in the request
3184 is not supported. The "closest" version number supported MUST
3185 be returned in the response.
3186
3187 server-error-device-error: a device error occurred while
3188 receiving or spooling the request or document data or the IPP
3189 Printer object can only accept one job at a time.
3190
3191
3192
3193
3194Hastings, et al. Informational [Page 57]
3195\f
3196RFC 3196 Internet Printing Protocol/1.1 November 2001
3197
3198
3199 server-error-temporary-error: a temporary error such as a
3200 buffer full write error, a memory overflow, or a disk full
3201 condition occurred while receiving the request and/or the
3202 document data.
3203
3204 server-error-not-accepting-jobs: the Printer object's
3205 "printer-is-not-accepting-jobs" attribute is 'false'.
3206
3207 server-error-busy: the Printer is too busy processing jobs to
3208 accept another job at this time.
3209
3210 server-error-job-canceled: the job has been canceled by an
3211 operator or the system while the client was transmitting the
3212 document data.
3213
32143.1.3.1.2 Print-URI
3215
3216 All of the Print-Job status codes described in Section 3.1.3.1.1
3217 Print-Job Response are applicable to Print-URI with the following
3218 specializations and differences. See Section 14 for a more complete
3219 description of each status code.
3220
3221 client-error-uri-scheme-not-supported: the URI scheme supplied
3222 in the "document-uri" operation attribute is not supported and
3223 is returned in the Unsupported Attributes group.
3224
3225 server-error-operation-not-supported: the Print-URI operation
3226 is not supported.
3227
32283.1.3.1.3 Validate-Job
3229
3230 All of the Print-Job status codes described in Section 3.1.3.1.1
3231 Print-Job Response are applicable to Validate-Job. See Section 13 in
3232 [RFC2911] for a more complete description of each status code.
3233
32343.1.3.1.4 Create-Job
3235
3236 All of the Print-Job status codes described in Section 3.1.3.1.1
3237 Print-Job Response are applicable to Create-Job with the following
3238 specializations and differences. See Section 13 in [RFC2911] for a
3239 more complete description of each status code.
3240
3241 server-error-operation-not-supported: the Create-Job operation
3242 is not supported.
3243
3244
3245
3246
3247
3248
3249
3250Hastings, et al. Informational [Page 58]
3251\f
3252RFC 3196 Internet Printing Protocol/1.1 November 2001
3253
3254
3255 client-error-multiple-document-jobs-not-supported: while the
3256 Create-Job and Send-Document operations are supported, this
3257 implementation doesn't support more than one document with
3258 data.
3259
32603.1.3.1.5 Get-Printer-Attributes
3261
3262 All of the Print-Job status codes described in Section
3263 3.1.3.1.1 Print-Job Response are applicable to the Get-
3264 Printer-Attributes operation with the following
3265 specialization's and differences. See Section 13 in [RFC2911]
3266 for a more complete description of each status code.
3267
3268 For the following success status codes, the requested
3269 attributes are returned in Group 3 in the response:
3270
3271 successful-ok: no operation attributes or values were
3272 substituted or ignored (same as Print-Job) and no requested
3273 attributes were unsupported.
3274
3275 successful-ok-ignored-or-substituted-attributes: The
3276 "requested-attributes" operation attribute MAY, but NEED NOT,
3277 be returned with the unsupported values.
3278
3279 successful-ok-conflicting-attributes: same as Print-Job.
3280
3281 For the error status codes, Group 3 is returned containing no
3282 attributes or is not returned at all:
3283
3284 client-error-not-possible: Same as Print-Job, in addition the
3285 Printer object is not accepting any requests.
3286
3287 client-error-request-entity-too-large: same as Print-job,
3288 except that no print data is involved.
3289
3290 client-error-attributes-or-values-not-supported: not
3291 applicable, since unsupported operation attributes and/or
3292 values MUST be ignored and an appropriate success code returned
3293 (see above).
3294
3295 client-error-conflicting-attributes: same as Print-Job, except
3296 that "ipp-attribute-fidelity" is not involved.
3297
3298 server-error-operation-not-supported: not applicable (since
3299 Get-Printer-Attributes is REQUIRED).
3300
3301 server-error-device-error: same as Print-Job, except that no
3302 document data is involved.
3303
3304
3305
3306Hastings, et al. Informational [Page 59]
3307\f
3308RFC 3196 Internet Printing Protocol/1.1 November 2001
3309
3310
3311 server-error-temporary-error: same as Print-Job, except that
3312 no document data is involved.
3313
3314 server-error-not-accepting-jobs: not applicable.
3315
3316 server-error-busy: same as Print-Job, except the IPP object is
3317 too busy to accept even query requests.
3318
3319 server-error-job-canceled: not applicable.
3320
33213.1.3.1.6 Get-Jobs
3322
3323 All of the Print-Job status codes described in Section 3.1.3.1.1
3324 Print-Job Response are applicable to the Get-Jobs operation with the
3325 following specialization's and differences. See Section 13 in
3326 [RFC2911] for a more complete description of each status code.
3327
3328 For the following success status codes, the requested attributes are
3329 returned in Group 3 in the response:
3330
3331 successful-ok: same as Get-Printer-Attributes (see section
3332 3.1.3.1.5).
3333
3334 successful-ok-ignored-or-substituted-attributes: same as Get-
3335 Printer-Attributes (see section 3.1.3.1.5).
3336
3337 successful-ok-conflicting-attributes: same as Get-Printer-
3338 Attributes (see section 3.1.3.1.5).
3339
3340 For any error status codes, Group 3 is returned containing no
3341 attributes or is not returned at all. The following brief error
3342 status code descriptions contain unique information for use with
3343 Get-Jobs operation. See section 14 for the other error status codes
3344 that apply uniformly to all operations:
3345
3346 client-error-not-possible: Same as Print-Job, in addition the
3347 Printer object is not accepting any requests.
3348
3349 client-error-request-entity-too-large: same as Print-job,
3350 except that no print data is involved.
3351
3352 client-error-document-format-not-supported: not applicable.
3353
3354 client-error-attributes-or-values-not-supported: not
3355 applicable, since unsupported operation attributes and/or
3356 values MUST be ignored and an appropriate success code returned
3357 (see above).
3358
3359
3360
3361
3362Hastings, et al. Informational [Page 60]
3363\f
3364RFC 3196 Internet Printing Protocol/1.1 November 2001
3365
3366
3367 client-error-conflicting-attributes: same as Print-Job, except
3368 that "ipp-attribute-fidelity" is not involved.
3369
3370 server-error-operation-not-supported: not applicable (since
3371 Get-Jobs is REQUIRED).
3372
3373 server-error-device-error: same as Print-Job, except that no
3374 document data is involved.
3375
3376 server-error-temporary-error: same as Print-Job, except that
3377 no document data is involved.
3378
3379 server-error-not-accepting-jobs: not applicable.
3380
3381 server-error-job-canceled: not applicable.
3382
33833.1.3.1.7 Pause-Printer
3384
3385 All of the Print-Job status codes described in Section 3.1.3.1.1
3386 Print-Job Response are applicable to Pause-Printer with the following
3387 specializations and differences. See Section 13 in [RFC2911] for a
3388 more complete description of each status code.
3389
3390 For the following success status codes, the Printer object is being
3391 stopped from scheduling jobs on all its devices.
3392
3393 successful-ok: no request attributes were substituted or
3394 ignored (same as Print-Job).
3395
3396 successful-ok-ignored-or-substituted-attributes: same as
3397 Print-Job.
3398
3399 successful-ok-conflicting-attributes: same as Print-Job.
3400
3401 For any of the error status codes, the Printer object has not been
3402 stopped from scheduling jobs on all its devices.
3403
3404 client-error-not-possible: not applicable.
3405
3406 client-error-not-found: the target Printer object does not
3407 exist.
3408
3409 client-error-gone: the target Printer object no longer exists
3410 and no forwarding address is known.
3411
3412 client-error-request-entity-too-large: same as Print-Job,
3413 except no document data is involved.
3414
3415
3416
3417
3418Hastings, et al. Informational [Page 61]
3419\f
3420RFC 3196 Internet Printing Protocol/1.1 November 2001
3421
3422
3423 client-error-document-format-not-supported: not applicable.
3424
3425 client-error-conflicting-attributes: same as Print-Job, except
3426 that the Printer's "printer-is-accepting-jobs" attribute is not
3427 involved.
3428
3429 server-error-operation-not-supported: the Pause-Printer
3430 operation is not supported.
3431
3432 server-error-device-error: not applicable.
3433
3434 server-error-temporary-error: same as Print-Job, except no
3435 document data is involved.
3436
3437 server-error-not-accepting-jobs: not applicable.
3438
3439 server-error-job-canceled: not applicable.
3440
34413.1.3.1.8 Resume-Printer
3442
3443 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3444 Print-Job Response with the specialization's described for Pause-
3445 Printer are applicable to Resume-Printer. See Section 13 in
3446 [RFC2911] for a more complete description of each status code.
3447
3448 For the following success status codes, the Printer object resumes
3449 scheduling jobs on all its devices.
3450
3451 successful-ok: no request attributes were substituted or
3452 ignored (same as Print-Job).
3453
3454 successful-ok-ignored-or-substituted-attributes: same as
3455 Print-Job.
3456
3457 successful-ok-conflicting-attributes: same as Print-Job.
3458
3459 For any of the error status codes, the Printer object does not resume
3460 scheduling jobs.
3461
3462 server-error-operation-not-supported: the Resume-Printer
3463 operation is not supported.
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474Hastings, et al. Informational [Page 62]
3475\f
3476RFC 3196 Internet Printing Protocol/1.1 November 2001
3477
3478
34793.1.3.1.8.1 What about Printers unable to change state due to an error
3480 condition?
3481
3482 If, in case, the IPP printer is unable to change its state due to
3483 some problem with the actual printer device (say, it is shut down or
3484 there is a media-jam as indicated in [RFC2911]), what should be the
3485 result of the "Resume-Printer" operation? Should it still change the
3486 'printer-state-reasons' and return success or should it fail ?
3487
3488 The Resume-Printer operation must clear the 'paused' or 'moving-to-
3489 paused' 'printer-state-message'. The operation must return a
3490 'successful-ok' status code.
3491
34923.1.3.1.8.2 How is "printer-state" handled on Resume-Printer?
3493
3494 If the Resume-Printer operation succeeds, what should be the value of
3495 "printer-state" and who should take care of the "printer-state"
3496 attribute value later on ?
3497
3498 The Resume-Printer operation may change the "printer-state-reasons"
3499 value.
3500
3501 The "printer-state" will change to one of three states:
3502
3503 1. 'idle' - no additional jobs and no error conditions present
3504
3505 2. 'processing' - job available and no error conditions present
3506
3507 3. current state (i.e. no change) an error condition is present
3508 (e.g. media jam)
3509
3510 In the third case the "printer-state-reason" will be cleared by
3511 automata when it detects the error condition no longer exists. The
3512 "printer-state" will move to 'idle' or 'processing' when conditions
3513 permit. (i.e. no more error conditions)
3514
35153.1.3.1.9 Purge-Printer
3516
3517 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3518 Print-Job Response with the specialization's described for Pause-
3519 Printer are applicable to Purge-Printer. See Section 13 in [RFC2911]
3520 for a more complete description of each status code.
3521
3522 For the following success status codes, the Printer object purges all
3523 it's jobs.
3524
3525 successful-ok: no request attributes were substituted or
3526 ignored (same as Print-Job).
3527
3528
3529
3530Hastings, et al. Informational [Page 63]
3531\f
3532RFC 3196 Internet Printing Protocol/1.1 November 2001
3533
3534
3535 successful-ok-ignored-or-substituted-attributes: same as
3536 Print-Job.
3537
3538 successful-ok-conflicting-attributes: same as Print-Job.
3539
3540 For any of the error status codes, the Printer object does not purge
3541 any jobs.
3542
3543 server-error-operation-not-supported: the Purge-Printer
3544 operation is not supported.
3545
35463.1.3.2 Job Operations
3547
35483.1.3.2.1 Send-Document
3549
3550 All of the Print-Job status codes described in Section 3.1.3.1.1
3551 Print-Job Response are applicable to the Get-Printer-Attributes
3552 operation with the following specialization's and differences. See
3553 Section 13 in [RFC2911] for a more complete description of each
3554 status code.
3555
3556 For the following success status codes, the document has been added
3557 to the specified Job object and the job's "number-of-documents"
3558 attribute has been incremented:
3559
3560 successful-ok: no request attributes were substituted or
3561 ignored (same as Print-Job).
3562
3563 successful-ok-ignored-or-substituted-attributes: same as
3564 Print-Job.
3565
3566 successful-ok-conflicting-attributes: same as Print-Job.
3567
3568 For the error status codes, no document has been added to the Job
3569 object and the job's "number-of-documents" attribute has not been
3570 incremented:
3571
3572 client-error-not-possible: Same as Print-Job, except that the
3573 Printer's "printer-is-accepting-jobs" attribute is not
3574 involved, so that the client is able to finish submitting a job
3575 that was created with a Create-Job operation after this
3576 attribute has been set to 'true'. Another condition is that
3577 the state of the job precludes Send-Document, i.e., the job has
3578
3579
3580
3581
3582
3583
3584
3585
3586Hastings, et al. Informational [Page 64]
3587\f
3588RFC 3196 Internet Printing Protocol/1.1 November 2001
3589
3590
3591 already been closed out by the client. However, if the IPP
3592 Printer closed out the job due to timeout, the 'client-error-
3593 timeout' error status SHOULD be returned instead.
3594
3595 client-error-timeout: This request was sent after the Printer
3596 closed the job, because it has not received a Send-Document or
3597 Send-URI operation within the Printer's "multiple-operation-
3598 time-out" period .
3599
3600 client-error-request-entity-too-large: same as Print-Job.
3601
3602 client-error-conflicting-attributes: same as Print-Job, except
3603 that "ipp-attributes-fidelity" operation attribute is not
3604 involved..
3605
3606 server-error-operation-not-supported: the Send-Document
3607 request is not supported.
3608
3609 server-error-not-accepting-jobs: not applicable.
3610
3611 server-error-job-canceled: the job has been canceled by an
3612 operator or the system while the client was transmitting the
3613 data.
3614
36153.1.3.2.2 Send-URI
3616
3617 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3618 Print-Job Response with the specialization's described for Send-
3619 Document are applicable to Send-URI. See Section 13 in [RFC2911] for
3620 a more complete description of each status code.
3621
3622 client-error-uri-scheme-not-supported: the URI scheme supplied
3623 in the "document-uri" operation attribute is not supported and
3624 the "document-uri" attribute MUST be returned in the
3625 Unsupported Attributes group.
3626
3627 server-error-operation-not-supported: the Send-URI operation is
3628 not supported.
3629
36303.1.3.2.3 Cancel-Job
3631
3632 All of the Print-Job status codes described in Section 3.1.3.1.1
3633 Print-Job Response are applicable to Cancel-Job with the following
3634 specializations and differences. See Section 13 in [RFC2911] for a
3635 more complete description of each status code.
3636
3637 For the following success status codes, the Job object is being
3638 canceled or has been canceled:
3639
3640
3641
3642Hastings, et al. Informational [Page 65]
3643\f
3644RFC 3196 Internet Printing Protocol/1.1 November 2001
3645
3646
3647 successful-ok: no request attributes were substituted or
3648 ignored (same as Print-Job).
3649
3650 successful-ok-ignored-or-substituted-attributes: same as
3651 Print-Job.
3652
3653 successful-ok-conflicting-attributes: same as Print-Job.
3654
3655 For any of the error status codes, the Job object has not been
3656 canceled or was previously canceled.
3657
3658 client-error-not-possible: The request cannot be carried out
3659 because of the state of the Job object ('completed',
3660 'canceled', or 'aborted') or the state of the system.
3661
3662 client-error-not-found: the target Printer and/or Job object
3663 does not exist.
3664
3665 client-error-gone: the target Printer and/or Job object no
3666 longer exists and no forwarding address is known.
3667
3668 client-error-request-entity-too-large: same as Print-Job,
3669 except no document data is involved.
3670
3671 client-error-document-format-not-supported: not applicable.
3672
3673 client-error-attributes-or-values-not-supported: not
3674 applicable, since unsupported operation attributes and values
3675 MUST be ignored.
3676
3677 client-error-conflicting-attributes: same as Print-Job, except
3678 that the Printer's "printer-is-accepting-jobs" attribute is not
3679 involved.
3680
3681 server-error-operation-not-supported: not applicable (Cancel-
3682 Job is REQUIRED).
3683
3684 server-error-device-error: same as Print-Job, except no
3685 document data is involved.
3686
3687 server-error-temporary-error: same as Print-Job, except no
3688 document data is involved.
3689
3690 server-error-not-accepting-jobs: not applicable.
3691
3692 server-error-job-canceled: not applicable.
3693
3694
3695
3696
3697
3698Hastings, et al. Informational [Page 66]
3699\f
3700RFC 3196 Internet Printing Protocol/1.1 November 2001
3701
3702
37033.1.3.2.4 Get-Job-Attributes
3704
3705 All of the Print-Job status codes described in Section 3.1.3.1.1
3706 Print-Job Response are applicable to Get-Job-Attributes with the
3707 following specializations and differences. See Section 13 in
3708 [RFC2911] for a more complete description of each status code.
3709
3710 For the following success status codes, the requested attributes are
3711 returned in Group 3 in the response:
3712
3713 successful-ok: same as Get-Printer-Attributes (see section
3714 3.1.3.1.5).
3715
3716 successful-ok-ignored-or-substituted-attributes: same as Get-
3717 Printer-Attributes (see section 3.1.3.1.5).
3718
3719 successful-ok-conflicting-attributes: same as Get-Printer-
3720 Attributes (see section 3.1.3.1.5).
3721
3722 For the error status codes, Group 3 is returned containing no
3723 attributes or is not returned at all.
3724
3725 client-error-not-possible: Same as Print-Job, in addition the
3726 Printer object is not accepting any requests.
3727
3728 client-error-document-format-not-supported: not applicable.
3729
3730 client-error-attributes-or-values-not-supported: not
3731 applicable.
3732
3733 client-error-uri-scheme-not-supported: not applicable.
3734
3735 client-error-attributes-or-values-not-supported: not
3736 applicable, since unsupported operation attributes and/or
3737 values MUST be ignored and an appropriate success code returned
3738 (see above).
3739
3740 client-error-conflicting-attributes: not applicable
3741
3742 server-error-operation-not-supported: not applicable (since
3743 Get-Job-Attributes is REQUIRED).
3744
3745 server-error-device-error: same as Print-Job, except no
3746 document data is involved.
3747
3748 server-error-temporary-error: sane as Print-Job, except no
3749 document data is involved..
3750
3751
3752
3753
3754Hastings, et al. Informational [Page 67]
3755\f
3756RFC 3196 Internet Printing Protocol/1.1 November 2001
3757
3758
3759 server-error-not-accepting-jobs: not applicable.
3760
3761 server-error-job-canceled: not applicable.
3762
37633.1.3.2.5 Hold-Job
3764
3765 All of the Print-Job status codes described in Section 3.1.3.1.1
3766 Print-Job Response are applicable to Hold-Job with the following
3767 specializations and differences. See Section 13 in [RFC2911] for a
3768 more complete description of each status code.
3769
3770 For the following success status codes, the Job object is being held
3771 or has been held:
3772
3773 successful-ok: no request attributes were substituted or
3774 ignored (same as Print-Job).
3775
3776 successful-ok-ignored-or-substituted-attributes: same as
3777 Print-Job.
3778
3779 successful-ok-conflicting-attributes: same as Print-Job.
3780
3781 For any of the error status codes, the Job object has not been held
3782 or was previously held.
3783
3784 client-error-not-possible: The request cannot be carried out
3785 because of the state of the Job object ('completed',
3786 'canceled', or 'aborted') or the state of the system.
3787
3788 client-error-not-found: the target Printer and/or Job object
3789 does not exist.
3790
3791 client-error-gone: the target Printer and/or Job object no
3792 longer exists and no forwarding address is known.
3793
3794 client-error-request-entity-too-large: same as Print-Job,
3795 except no document data is involved.
3796
3797 client-error-document-format-not-supported: not applicable.
3798
3799 client-error-conflicting-attributes: same as Print-Job, except
3800 that the Printer's "printer-is-accepting-jobs" attribute is not
3801 involved.
3802
3803 server-error-operation-not-supported: the Hold-Job operation is
3804 not supported.
3805
3806 server-error-device-error: not applicable.
3807
3808
3809
3810Hastings, et al. Informational [Page 68]
3811\f
3812RFC 3196 Internet Printing Protocol/1.1 November 2001
3813
3814
3815 server-error-temporary-error: same as Print-Job, except no
3816 document data is involved.
3817
3818 server-error-not-accepting-jobs: not applicable.
3819
3820 server-error-job-canceled: not applicable.
3821
38223.1.3.2.6 Release-Job
3823
3824 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3825 Print-Job Response with the specialization's described for Hold-Job
3826 are applicable to Release-Job. See Section 13 in [RFC2911] for a
3827 more complete description of each status code.
3828
3829 server-error-operation-not-supported: the Release-Job operation
3830 is not supported.
3831
38323.1.3.2.7 Restart-Job
3833
3834 All of the Print-Job status code descriptions in Section 3.1.3.1.1
3835 Print-Job Response with the specialization's described for Hold-Job
3836 are applicable to Restart-Job. See Section 13 in [RFC2911] for a
3837 more complete description of each status code.
3838
3839 server-error-operation-not-supported: the Restart-Job operation
3840 is not supported.
3841
38423.1.3.2.7.1 Can documents be added to a restarted job?
3843
3844 Assume I give a Create-Job request along with a set of 5 documents.
3845 All the documents get printed and the job state is moved to
3846 completed. I issue a Restart-Job request on the job. Now the issue
3847 is that, if I try to add new documents to the restarted job, will the
3848 IPP Server permit me to do so or return "client-error-not-possible "
3849 and again print those 5 jobs?
3850
3851 A job can not move to the 'completed' state until all the documents
3852 have been processed. The 'last-document' flag indicates when the
3853 last document for a job is being sent from the client. This is the
3854 semantic equivalent of closing a job. No documents may be added once
3855 a job is closed. Section 3.3.7 of the IPP/1.1 model states "The job
3856 is moved to the 'pending' job state and restarts the beginning on the
3857 same IPP Printer object with the same attribute values." 'number-
3858 of-documents' is a job attribute.
3859
3860
3861
3862
3863
3864
3865
3866Hastings, et al. Informational [Page 69]
3867\f
3868RFC 3196 Internet Printing Protocol/1.1 November 2001
3869
3870
38713.1.4 Returning unsupported attributes in Get-Xxxx responses (Issue
3872 1.18)
3873
3874 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
3875 responses, the client cannot depend on getting unsupported attributes
3876 returned in the Unsupported Attributes group that the client
3877 requested, but are not supported by the IPP object. However, such
3878 unsupported requested attributes will not be returned in the Job
3879 Attributes or Printer Attributes group (since they are unsupported).
3880 Furthermore, the IPP object is REQUIRED to return the 'successful-
3881 ok-ignored-or-substituted-attributes' status code, so that the client
3882 knows that not all that was requested has been returned.
3883
38843.1.5 Sending empty attribute groups
3885
3886 The [RFC2911] and [RFC2910] specifications RECOMMEND that a sender
3887 not send an empty attribute group in a request or a response.
3888 However, they REQUIRE a receiver to accept an empty attribute group
3889 as equivalent to the omission of that group. So a client SHOULD omit
3890 the Job Template Attributes group entirely in a create operation that
3891 is not supplying any Job Template attributes. Similarly, an IPP
3892 object SHOULD omit an empty Unsupported Attributes group if there are
3893 no unsupported attributes to be returned in a response.
3894
3895 The [RFC2910] specification REQUIRES a receiver to be able to receive
3896 either an empty attribute group or an omitted attribute group and
3897 treat them equivalently. The term "receiver" means an IPP object for
3898 a request and a client for a response. The term "sender' means a
3899 client for a request and an IPP object for a response.
3900
3901 There is an exception to the rule for Get-Jobs when there are no
3902 attributes to be returned. [RFC2910] contains the following
3903 paragraph:
3904
3905 The syntax allows an xxx-attributes-tag to be present when the xxx-
3906 attribute-sequence that follows is empty. The syntax is defined this
3907 way to allow for the response of Get-Jobs where no attributes are
3908 returned for some job-objects. Although it is RECOMMENDED that the
3909 sender not send an xxx-attributes-tag if there are no attributes
3910 (except in the Get-Jobs response just mentioned), the receiver MUST
3911 be able to decode such syntax.
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922Hastings, et al. Informational [Page 70]
3923\f
3924RFC 3196 Internet Printing Protocol/1.1 November 2001
3925
3926
39273.2 Printer Operations
3928
39293.2.1 Print-Job operation
3930
39313.2.1.1 Flow controlling the data portion of a Print-Job request (Issue
3932 1.22)
3933
3934 A paused printer, or one that is stopped due to paper out or jam or
3935 spool space full or buffer space full, may flow control the data of a
3936 Print-Job operation (at the TCP/IP layer), so that the client is not
3937 able to send all the document data. Consequently, the Printer will
3938 not return a response until the condition is changed.
3939
3940 The Printer should not return a Print-Job response with an error code
3941 in any of these conditions, since either the printer will be resumed
3942 and/or the condition will be freed either by human intervention or as
3943 jobs print.
3944
3945 In writing test scripts to test IPP Printers, the script must also be
3946 written not to expect a response, if the printer has been paused,
3947 until the printer is resumed, in order to work with all possible
3948 implementations.
3949
39503.2.1.2 Returning job-state in Print-Job response (Issue 1.30)
3951
3952 An IPP client submits a small job via Print-Job. By the time the IPP
3953 printer/print server is putting together a response to the operation,
3954 the job has finished printing and been removed as an object from the
3955 print system. What should the job-state be in the response?
3956
3957 The Model suggests that the Printer return a response before it even
3958 accepts the document content. The Job Object Attributes are returned
3959 only if the IPP object returns one of the success status codes. Then
3960 the job-state would always be "pending" or "pending-held".
3961
3962 This issue comes up for the implementation of an IPP Printer object
3963 as a server that forwards jobs to devices that do not provide job
3964 status back to the server. If the server is reasonably certain that
3965 the job completed successfully, then it should return the job-state
3966 as 'completed'. Also the server can keep the job in its "job
3967 history" long after the job is no longer in the device. Then a user
3968 could query the server and see that the job was in the 'completed'
3969 state and completed as specified by the jobs "time-at-completed"
3970 time, which would be the same as the server submitted the job to the
3971 device.
3972
3973
3974
3975
3976
3977
3978Hastings, et al. Informational [Page 71]
3979\f
3980RFC 3196 Internet Printing Protocol/1.1 November 2001
3981
3982
3983 An alternative is for the server to respond to the client before or
3984 while sending the job to the device, instead of waiting until the
3985 server has finished sending the job to the device. In this case, the
3986 server can return the job's state as 'pending' with the 'job-
3987 outgoing' value in the job's "job-state-reasons" attribute.
3988
3989 If the server doesn't know for sure whether the job completed
3990 successfully (or at all), it could return the (out-of-band) 'unknown'
3991 value.
3992
3993 On the other hand, if the server is able to query the device and/or
3994 setup some sort of event notification that the device initiates when
3995 the job makes state transitions, then the server can return the
3996 current job state in the Print-Job response and in subsequent queries
3997 because the server knows what the job state is in the device (or can
3998 query the device).
3999
4000 All of these alternatives depend on implementation of the server and
4001 the device.
4002
40033.2.2 Get-Printer-Attributes operation
4004
4005 If a Printer supports the "printer-make-and-model" attribute and
4006 returns the .INF file model name of the printer in that attribute,
4007 the Microsoft client will automatically install the correct driver
4008 (if available).
4009
4010 Clients which poll periodically for printer status or queued-job-
4011 count should use the "requested-attributes" operation attribute to
4012 limit the scope of the query in order to save Printer and network
4013 resources.
4014
40153.2.3 Get-Jobs operation
4016
40173.2.3.1 Get-Jobs, my-jobs='true', and 'requesting-user-name' (Issue
4018 1.39)?
4019
4020 In [RFC2911] section 3.2.6.1 'Get-Jobs Request', if the attribute
4021 'my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
4022 attribute be there too, and if it's not present what should the IPP
4023 printer do?
4024
4025 [RFC2911] Section 8.3 describes the various cases of "requesting-
4026 user-name" being present or not for any operation. If the client
4027 does not supply a value for "requesting-user-name", the printer MUST
4028 assume that the client is supplying some anonymous name, such as
4029 "anonymous".
4030
4031
4032
4033
4034Hastings, et al. Informational [Page 72]
4035\f
4036RFC 3196 Internet Printing Protocol/1.1 November 2001
4037
4038
40393.2.3.2 Why is there a "limit" attribute in the Get-Jobs operation?
4040
4041 When using the Get-Jobs operation a client implementer might choose
4042 to limit the number of jobs that the client shows on the first
4043 screenful. For example, if its UI can only display 50 jobs, it can
4044 defend itself against a printer that would otherwise return 500 jobs,
4045 perhaps taking a long time on a slow dial-up line. The client can
4046 then go and ask for a larger number of jobs in the background, while
4047 showing the user the first 50 jobs. Since the job history is returned
4048 in reverse order, namely the most recently completed jobs are
4049 returned first, the user is most likely interested in the first jobs
4050 that are returned. Limiting the number of jobs may be especially
4051 useful for a client that is requesting 'completed' jobs from a
4052 printer that keeps a long job history. Clients that don't mind
4053 sometimes getting very large responses, can omit the "limit"
4054 attribute in their Get-Jobs requests.
4055
40563.2.4 Create-Job operation
4057
4058 A Printer may respond to a Create-Job operation with "job-state"
4059 'pending' or 'pending-held' and " job-state-reason" 'job-data-
4060 insufficient' to indicate that operation has been accepted by the
4061 Printer, but the Printer is expecting additional document data before
4062 it can move the job into the 'processing' state. Alternatively, it
4063 may respond with "job-state" 'processing' and "job-state-reason"
4064 'job-incoming' to indicate that the Create-Job operation has been
4065 accepted by the Printer, but the Printer is expecting additional
4066 Send-Document and/or Send-URI operations and/or is
4067 accessing/accepting document data. The second alternative is for
4068 non-spooling Printers that don't implement the 'pending' state.
4069
4070 Should the server wait for the "last-document" operation attribute
4071 set to 'true' before starting to "process" the job?
4072
4073 It depends on implementation. Some servers spool the entire job,
4074 including all document data, before starting to process, so such an
4075 implementation would wait for the "last-document" before starting to
4076 process the job. If the time-out occurs without the "last-document",
4077 then the server takes one of the indicated actions in section 3.3.1
4078 in the [RFC2911] document. Other servers will start to process
4079 document data as soon as they have some. These are the so-called
4080 "non-spooling" printers. Currently, there isn't a way for a client to
4081 determine whether the Printer will spool all the data or will start
4082 to process (and print) as soon as it has some data.
4083
4084
4085
4086
4087
4088
4089
4090Hastings, et al. Informational [Page 73]
4091\f
4092RFC 3196 Internet Printing Protocol/1.1 November 2001
4093
4094
40953.3 Job Operations
4096
40973.3.1 Validate-Job
4098
4099 The Validate-Job operation has been designed so that its
4100 implementation may be a part of the Print-Job operation. Therefore,
4101 requiring Validate-Job is not a burden on implementers. Also it is
4102 useful for client's to be able to count on its presence in all
4103 conformance implementations, so that the client can determine before
4104 sending a long document, whether the job will be accepted by the IPP
4105 Printer or not.
4106
41073.3.2 Restart-Job
4108
4109 The Restart-Job operation allows the reprocessing of a completed job.
4110 Some jobs store the document data on the printer. Jobs created using
4111 the Print-Job operation are an example. It is required that the
4112 printer retains the job data after the job has moved to a 'completed
4113 state' in order for the Restart-Job operation to succeed.
4114
4115 Some jobs contain only a reference to the job data. A job created
4116 using the Print-URI is an example of such a job. When the Restart-
4117 Job operation is issued the job is reprocessed. The job data MUST be
4118 retrieved again to print the job.
4119
4120 It is possible that a job fails while attempting to access the print
4121 data. When such a job is the target of a Restart-Job the Printer
4122 SHALL attempt to retrieve the job data again.
4123
41244 Object Attributes
4125
41264.1 Attribute Syntax's
4127
41284.1.1 The 'none' value for empty sets (Issue 1.37)
4129
4130 [RFC2911] states that the 'none' value should be used as the value of
4131 a 1setOf when the set is empty. In most cases, sets that are
4132 potentially empty contain keywords so the keyword 'none' is used, but
4133 for the 3 finishings attributes, the values are enums and thus the
4134 empty set is represented by the enum 3. Currently there are no other
4135 attributes with 1setOf values, which can be empty and can contain
4136 values that are not keywords. This exception requires special code
4137 and is a potential place for bugs. It would have been better if we
4138 had chosen an out-of-band value, either "no-value" or some new value,
4139 such as 'none'. Since we didn't, implementations have to deal with
4140 the different representations of 'none', depending on the attribute
4141 syntax.
4142
4143
4144
4145
4146Hastings, et al. Informational [Page 74]
4147\f
4148RFC 3196 Internet Printing Protocol/1.1 November 2001
4149
4150
41514.1.2 Multi-valued attributes (Issue 1.31)
4152
4153 What is the attribute syntax for a multi-valued attribute? Since
4154 some attributes support values in more than one data type, such as
4155 "media", "job-hold-until", and "job-sheets", IPP semantics associate
4156 the attribute syntax with each value, not with the attribute as a
4157 whole. The protocol associates the attribute syntax tag with each
4158 value. Don't be fooled, just because the attribute syntax tag comes
4159 before the attribute keyword. All attribute values after the first
4160 have a zero length attribute keyword as the indication of a
4161 subsequent value of the same attribute.
4162
41634.1.3 Case Sensitivity in URIs (issue 1.6)
4164
4165 IPP client and server implementations must be aware of the diverse
4166 uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and
4167 Host names as case insensitive but reminds us that the rest of the
4168 URL may well demonstrate case sensitivity. When creating URL's for
4169 fields where the choice is completely arbitrary, it is probably best
4170 to select lower case. However, this cannot be guaranteed and
4171 implementations MUST NOT rely on any fields being case-sensitive or
4172 case-insensitive in the URL beyond the URL scheme and host name
4173 fields.
4174
4175 The reason that the IPP specification does not make any restrictions
4176 on URIs, is so that implementations of IPP may use off-the-shelf
4177 components that conform to the standards that define URIs, such as
4178 RFC 2396 and the HTTP/1.1 specifications [RFC2616]. See these
4179 specifications for rules of matching, comparison, and case-
4180 sensitivity.
4181
4182 It is also recommended that System Administrators and implementations
4183 avoid creating URLs for different printers that differ only in their
4184 case. For example, don't have Printer1 and printer1 as two different
4185 IPP Printers.
4186
4187 Example of equivalent URI's
4188
4189 http://abc.com:80/~smith/home.html
4190
4191 http://ABC.com/%7Esmith/home.html
4192
4193 http:/ABC.com:/%7esmith/home.html
4194
4195 Example of equivalent URI's using the IPP scheme
4196
4197 ipp://abc.com:631/~smith/home.html
4198
4199
4200
4201
4202Hastings, et al. Informational [Page 75]
4203\f
4204RFC 3196 Internet Printing Protocol/1.1 November 2001
4205
4206
4207 ipp://ABC.com/%7Esmith/home.html
4208
4209 http:/ABC.com:631/%7esmith/home.html
4210
4211 The HTTP/1.1 specification [RFC2616] contains more details on
4212 comparing URLs.
4213
42144.1.4 Maximum length for xxxWithLanguage and xxxWithoutLanguage
4215
4216 The 'textWithLanguage' and 'nameWithLanguage' are compound syntaxes
4217 that have two components. The first component is the 'language'
4218 component that can contain up to 63 octets. The second component is
4219 the 'text' or 'name' component. The maximum length of these are 1023
4220 octets and 255 octets respectively. The definition of attributes
4221 with either syntax may further restrict the length (e.g., printer-
4222 name (name(127))).
4223
4224 The length of the 'language' component has no effect on the allowable
4225 length of 'text' in 'textWithLanguage' or the length of 'name' in
4226 'nameWithLanguage'
4227
42284.2 Job Template Attributes
4229
42304.2.1 multiple-document-handling(type2 keyword)
4231
42324.2.1.1 Support of multiple document jobs
4233
4234 IPP/1.0 is silent on which of the four effects an implementation
4235 would perform if it supports Create-Job, but does not support
4236 "multiple-document-handling" or multiple documents per job. IPP/1.1
4237 was changed so that a Printer could support Create-Job without having
4238 to support multiple document jobs. The "multiple-document-jobs-
4239 supported" (boolean) Printer description attribute was added to
4240 IPP/1.1 along with the 'server-error-multiple-document-jobs-not-
4241 supported' status code for a Printer to indicate whether or not it
4242 supports multiple document jobs, when it supports the Create-Job
4243 operation. Also IPP/1.1 was clarified that the Printer MUST support
4244 the "multiple-document-handling" (type2 keyword) Job Template
4245 attribute with at least one value if the Printer supports multiple
4246 documents per job.
4247
42484.3 Job Description Attributes
4249
42504.3.1 Getting the date and time of day
4251
4252 The "date-time-at-creation", "date-time-at-processing", and "date-
4253 time-at-completed" attributes are returned as dateTime syntax. These
4254 attributes are OPTIONAL for a Printer to support. However, there are
4255
4256
4257
4258Hastings, et al. Informational [Page 76]
4259\f
4260RFC 3196 Internet Printing Protocol/1.1 November 2001
4261
4262
4263 various ways for a Printer to get the date and time of day. Some
4264 suggestions:
4265
4266 1. A Printer can get time from an NTP timeserver if there's one
4267 reachable on the network . See RFC 1305. Also DHCP option 32
4268 in RFC 2132 returns the IP address of the NTP server.
4269
4270 2. Get the date and time at startup from a human operator
4271
4272 3. Have an operator set the date and time using a web
4273 administrative interface
4274
4275 4. Get the date and time from incoming HTTP requests, though the
4276 problems of spoofing need to be considered. Perhaps comparing
4277 several HTTP requests could reduce the chances of spoofing.
4278
4279 5. Internal date time clock battery driven.
4280
4281 6. Query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4282
42834.4 Printer Description Attributes
4284
42854.4.1 queued-job-count (integer(0:MAX))
4286
42874.4.1.1 Why is "queued-job-count" RECOMMENDED (Issue 1.14)?
4288
4289 The reason that "queued-job-count" is RECOMMENDED, is that some
4290 clients look at that attribute alone when summarizing the status of a
4291 list of printers, instead of doing a Get-Jobs to determine the number
4292 of jobs in the queue. Implementations that fail to support the
4293 "queued-job-count" will cause that client to display 0 jobs when
4294 there are actually queued jobs.
4295
4296 We would have made it a REQUIRED Printer attribute, but some
4297 implementations had already been completed before the issue was
4298 raised, so making it a SHOULD was a compromise.
4299
43004.4.1.2 Is "queued-job-count" a good measure of how busy a printer is
4301 (Issue 1.15)?
4302
4303 The "queued-job-count" is not a good measure of how busy the printer
4304 is when there are held jobs. A future registration could be to add a
4305 "held-job-count" (or an "active-job-count") Printer Description
4306 attribute if experience shows that such an attribute (combination) is
4307 needed to quickly indicate how busy a printer really is.
4308
4309
4310
4311
4312
4313
4314Hastings, et al. Informational [Page 77]
4315\f
4316RFC 3196 Internet Printing Protocol/1.1 November 2001
4317
4318
43194.4.2 printer-current-time (dateTime)
4320
4321 A Printer implementation MAY support this attribute by obtaining the
4322 date and time by any number of implementation-dependent means at
4323 startup or subsequently. Examples include:
4324
4325 1. an internal date time clock,
4326
4327 2. from the operator at startup using the console,
4328
4329 3. from an operator using an administrative web page,
4330
4331 4. from HTTP headers supplied in client requests,
4332
4333 5. use HTTP to query "http://tycho.usno.navy.mil/cgi-bin/timer.pl"
4334
4335 6. from the network, using NTP [RFC1305] or DHCP option 32
4336 [RFC2132] that returns the IP address of the NTP server.
4337
4338 If an implementation supports this attribute by obtaining the current
4339 time from the network (at startup or later), but the time is not
4340 available, then the implementation MUST return the value of this
4341 attribute using the out-of-band 'no-value' meaning not configured.
4342 See the beginning of section 4.1.
4343
4344 Since the new "date-and-time-at-xxx" Job Description attributes refer
4345 to the "printer-current-time", they will be covered also.
4346
43474.4.3 Printer-uri
4348
4349 Must the operational attribute for printer-uri match one of the
4350 values in "printer-uri-supported"?
4351
4352 A forgiving printer implementation would not reject the operation.
4353 But the implementation has its rights to reject a printer or job
4354 operation if the operational attribute printer-uri is not a value of
4355 the printer-uri-supported. The printer might not be improperly
4356 configured. The request obviously reached the printer. The printer
4357 could treat the printer-uri as the logical equivalent of a value in
4358 the printer-uri-supported. It would be implementation dependent for
4359 which value, and associated security policy, would apply. This does
4360 also apply to a job object specified with a printer-uri and job-id,
4361 or with a job-uri. See section 4.1.3 for how to compare URI's.
4362
4363
4364
4365
4366
4367
4368
4369
4370Hastings, et al. Informational [Page 78]
4371\f
4372RFC 3196 Internet Printing Protocol/1.1 November 2001
4373
4374
43754.5 Empty Jobs
4376
4377 The IPP object model does not prohibit a job that contains no
4378 documents. Such a job may be created in a number of ways including a
4379 'create-job' followed by an 'add-document' that contains no data and
4380 has the 'last-document' flag set.
4381
4382 An empty job is processed just as any other job. The operation that
4383 "closes" an empty job is not rejected because the job is empty. If
4384 no other conditions exist, other than the job is empty, the response
4385 to the operation will indicate success. After the job is scheduled
4386 and processed, the job state SHALL be 'completed'.
4387
4388 There will be some variation in the value(s) of the "job-state-
4389 reasons" attribute. It is required that if no conditions, other than
4390 the job being empty, exist the "job-state-reasons" SHALL include the
4391
4392 'completed-successfully'. If other conditions existed, the
4393 'completed-with-warnings' or 'completed-with-errors' values may be
4394 used.
4395
43965 Directory Considerations
4397
43985.1 General Directory Schema Considerations
4399
4400 The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object
4401 attributes for directory schemas. See [RFC2911] APPENDIX E: Generic
4402 Directory Schema.
4403
4404 The SLP printer template is defined in the "Definition of the Printer
4405 Abstract Service Type v2.0" document [svrloc-printer]. The LDAP
4406 printer template is defined in the "Internet Printing Protocol (IPP):
4407 LDAP Schema for Printer Services" document [ldap-printer]. Both
4408 documents systematically add "printer-" to any attribute that doesn't
4409 already start with "printer-" in order to keep the printer directory
4410 attributes distinct from other directory attributes. Also, instead
4411 of using "printer-uri-supported", "uri-authentication-supported", and
4412 "uri-security-supported", they use a "printer-xri-supported"
4413 attribute with special syntax to contain all of the same information
4414 in a single attribute.
4415
44165.2 IPP Printer with a DNS name
4417
4418 If the IPP printer has a DNS name should there be at least two values
4419 for the printer-uri-supported attribute. One URL with the fully
4420 qualified DNS name the other with the IP address in the URL?
4421
4422
4423
4424
4425
4426Hastings, et al. Informational [Page 79]
4427\f
4428RFC 3196 Internet Printing Protocol/1.1 November 2001
4429
4430
4431 The printer may contain one or the other or both. It's up to the
4432 administrator to configure this attribute.
4433
44346 Security Considerations
4435
4436 The security considerations given in [RFC2911] Section 8 "Security
4437 Considerations" all apply to this document. In addition, the
4438 following sub-sections describes security consideration that have
4439 arisen as a result of implementation testing.
4440
44416.1 Querying jobs with IPP that were submitted using other job
4442 submission protocols (Issue 1.32)
4443
4444 The following clarification was added to [RFC2911] section 8.5:
4445
4446 8.5 Queries on jobs submitted using non-IPP protocols If the
4447 device that an IPP Printer is representing is able to accept jobs
4448 using other job submission protocols in addition to IPP, it is
4449 RECOMMEND that such an implementation at least allow such
4450 "foreign" jobs to be queried using Get-Jobs returning "job-id" and
4451 "job-uri" as 'unknown'. Such an implementation NEED NOT support
4452 all of the same IPP job attributes as for IPP jobs. The IPP
4453 object returns the 'unknown' out-of-band value for any requested
4454 attribute of a foreign job that is supported for IPP jobs, but not
4455 for foreign jobs.
4456
4457 It is further RECOMMENDED, that the IPP Printer generate "job-id"
4458 and "job-uri" values for such "foreign jobs", if possible, so that
4459 they may be targets of other IPP operations, such as Get-Job-
4460 Attributes and Cancel-Job. Such an implementation also needs to
4461 deal with the problem of authentication of such foreign jobs. One
4462 approach would be to treat all such foreign jobs as belonging to
4463 users other than the user of the IPP client. Another approach
4464 would be for the foreign job to belong to 'anonymous'. Only if
4465 the IPP client has been authenticated as an operator or
4466 administrator of the IPP Printer object, could the foreign jobs be
4467 queried by an IPP request. Alternatively, if the security policy
4468 were to allow users to query other users' jobs, then the foreign
4469 jobs would also be visible to an end-user IPP client using Get-
4470 Jobs and Get-Job- Attributes.
4471
4472 Thus IPP MAY be implemented as a "universal" protocol that
4473 provides access to jobs submitted with any job submission
4474 protocol. As IPP becomes widely implemented, providing a more
4475 universal access makes sense.
4476
4477
4478
4479
4480
4481
4482Hastings, et al. Informational [Page 80]
4483\f
4484RFC 3196 Internet Printing Protocol/1.1 November 2001
4485
4486
44877 Encoding and Transport
4488
4489 This section discusses various aspects of IPP/1.1 Encoding and
4490 Transport [RFC2910].
4491
4492 A server is not required to send a response until after it has
4493 received the client's entire request. Hence, a client must not
4494 expect a response until after it has sent the entire request.
4495 However, we recommend that the server return a response as soon as
4496 possible if an error is detected while the client is still sending
4497 the data, rather than waiting until all of the data is received.
4498 Therefore, we also recommend that a client listen for an error
4499 response that an IPP server MAY send before it receives all the data.
4500 In this case a client, if chunking the data, can send a premature
4501 zero-length chunk to end the request before sending all the data (and
4502 so the client can keep the connection open for other requests, rather
4503 than closing it). If the request is blocked for some reason, a
4504 client MAY determine the reason by opening another connection to
4505 query the server using Get-Printer-Attributes.
4506
4507 IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793]
4508 to throttle clients when Printers are busy. Therefore, it is
4509 perfectly normal for an IPP client transmitting a Job to be blocked
4510 for a really long time. Accordingly, socket timeouts must be
4511 avoided. Some socket implementations have a timeout option, which
4512 specifies how long a write operation on a socket can be blocked
4513 before it times out and the blocking ends. A client should set this
4514 option for infinite timeout when transmitting Job submissions.
4515
4516 Some IPP client applications might be able to perform other useful
4517 work while a Job transmission is blocked. For example, the client
4518 may have other jobs that it could transmit to other Printers
4519 simultaneously. A client may have a GUI, which must remain
4520 responsive to the user while the Job transmission is blocked. These
4521 clients should be designed to spawn a thread to handle the Job
4522 transmission at its own pace, leaving the main application free to do
4523 other work. Alternatively, single-threaded applications could use
4524 non-blocking I/O.
4525
4526 Some Printer conditions, such as jam or lack of paper, could cause a
4527 client to be blocked indefinitely. Clients may open additional
4528 connections to the Printer to Get-Printer-Attributes, determine the
4529 state of the device, alert a user if the printer is stopped, and let
4530 a user decide whether to abort the job transmission or not.
4531
4532 In the following sections, there are tables of all HTTP headers,
4533 which describe their use in an IPP client or server. The following
4534 is an explanation of each column in these tables.
4535
4536
4537
4538Hastings, et al. Informational [Page 81]
4539\f
4540RFC 3196 Internet Printing Protocol/1.1 November 2001
4541
4542
4543 - the "header" column contains the name of a header
4544 - the "request/client" column indicates whether a client sends the
4545 header.
4546 - the "request/ server" column indicates whether a server supports
4547 the header when received.
4548 - the "response/ server" column indicates whether a server sends
4549 the header.
4550 - the "response /client" column indicates whether a client
4551 supports the header when received.
4552 - the "values and conditions" column specifies the allowed header
4553 values and the conditions for the header to be present in a
4554 request/response.
4555
4556 The table for "request headers" does not have columns for responses,
4557 and the table for "response headers" does not have columns for
4558 requests.
4559
4560 The following is an explanation of the values in the "request/client"
4561 and "response/ server" columns.
4562
4563 - must: the client or server MUST send the header,
4564 - must-if: the client or server MUST send the header when the
4565 condition described in the "values and conditions" column is
4566 met,
4567 - may: the client or server MAY send the header
4568 - not: the client or server SHOULD NOT send the header. It is not
4569 relevant to an IPP implementation.
4570
4571 The following is an explanation of the values in the
4572 "response/client" and "request/ server" columns.
4573
4574 - must: the client or server MUST support the header,
4575 - may: the client or server MAY support the header
4576 - not: the client or server SHOULD NOT support the header. It is
4577 not relevant to an IPP implementation.
4578
4579
4580
4581
4582
4583
4584
4585
4586
4587
4588
4589
4590
4591
4592
4593
4594Hastings, et al. Informational [Page 82]
4595\f
4596RFC 3196 Internet Printing Protocol/1.1 November 2001
4597
4598
45997.1 General Headers
4600
4601 The following is a table for the general headers.
4602
4603 General- Request Response Values and Conditions
4604 Header
4605
4606 Client Server Server Client
4607
4608
4609 Cache- not must not "no-cache" only
4610 Control must
4611
4612 Connection must- must must- must "close" only. Both
4613 if if client and server
4614 SHOULD keep a
4615 connection for the
4616 duration of a sequence
4617 of operations. The
4618 client and server MUST
4619 include this header
4620 for the last operation
4621 in such a sequence.
4622
4623 Date may may must may per RFC 1123 [RFC1123]
4624 from RFC 2616
4625 [RFC2616]
4626
4627 Pragma must not must not "no-cache" only
4628
4629 Transfer- must- must must- must "chunked" only. Header
4630 Encoding if if MUST be present if
4631 Content-Length is
4632 absent.
4633
4634 Upgrade not not not not
4635
4636 Via not not not not
4637
4638
4639
4640
4641
4642
4643
4644
4645
4646
4647
4648
4649
4650Hastings, et al. Informational [Page 83]
4651\f
4652RFC 3196 Internet Printing Protocol/1.1 November 2001
4653
4654
46557.2 Request Headers
4656
4657 The following is a table for the request headers.
4658
4659 Request- Client Server Request Values and Conditions
4660 Header
4661
4662 Accept may must "application/ipp" only. This
4663 value is the default if the
4664 client omits it
4665
4666 Accept- not not Charset information is within the
4667 Charset application/ipp entity
4668
4669 Accept- may must empty and per RFC 2616 [RFC2616]
4670 Encoding and IANA registry for content-
4671 codings
4672
4673 Accept- not not language information is within the
4674 Language application/ipp entity
4675
4676 Authorization must- must per RFC 2616. A client MUST send
4677 if this header when it receives a
4678 401 "Unauthorized" response and
4679 does not receive a "Proxy-
4680 Authenticate" header.
4681
4682 From not not per RFC 2616. Because RFC
4683 recommends sending this header
4684 only with the user's approval,
4685 it is not very useful
4686
4687 Host must must per RFC 2616
4688
4689 If-Match not not
4690
4691 If-Modified- not not
4692 Since
4693
4694 If-None-Match not not
4695
4696 If-Range not not
4697
4698 If- not not
4699 Unmodified-
4700 Since
4701
4702
4703
4704
4705
4706Hastings, et al. Informational [Page 84]
4707\f
4708RFC 3196 Internet Printing Protocol/1.1 November 2001
4709
4710
4711 Request- Client Server Request Values and Conditions
4712 Header
4713
4714 Max-Forwards not not
4715
4716 Proxy- must- not per RFC 2616. A client MUST send
4717 Authorizati if this header when it receives a
4718 on 401 "Unauthorized" response and
4719 a "Proxy-Authenticate" header.
4720
4721 Range not not
4722
4723 Referrer not not
4724
4725 User-Agent not not
4726
4727
4728
4729
4730
4731
4732
4733
4734
4735
4736
4737
4738
4739
4740
4741
4742
4743
4744
4745
4746
4747
4748
4749
4750
4751
4752
4753
4754
4755
4756
4757
4758
4759
4760
4761
4762Hastings, et al. Informational [Page 85]
4763\f
4764RFC 3196 Internet Printing Protocol/1.1 November 2001
4765
4766
47677.3 Response Headers
4768
4769 The following is a table for the request headers.
4770
4771 Response- Server Client Response Values and Conditions
4772 Header
4773
4774
4775 Accept-Ranges not not
4776
4777 Age not not
4778
4779 Location must- may per RFC 2616. When URI needs
4780 if redirection.
4781
4782 Proxy- must per RFC 2616
4783 Authenticat
4784 e not
4785
4786 Public may may per RFC 2616
4787
4788 Retry-After may may per RFC 2616
4789
4790 Server not not
4791
4792 Vary not not
4793
4794 Warning may may per RFC 2616
4795
4796 WWW- must- must per RFC 2616. When a server needs
4797 Authenticate if to authenticate a client.
4798
4799
4800
4801
4802
4803
4804
4805
4806
4807
4808
4809
4810
4811
4812
4813
4814
4815
4816
4817
4818Hastings, et al. Informational [Page 86]
4819\f
4820RFC 3196 Internet Printing Protocol/1.1 November 2001
4821
4822
48237.4 Entity Headers
4824
4825 The following is a table for the entity headers.
4826
4827 Entity-Header Request Response Values and
4828 Conditions
4829
4830 Client Server Server Client
4831
4832 Allow not not not not
4833
4834 Content-Base not not not not
4835
4836 Content- may must must must per RFC 2616 and
4837 Encoding IANA registry for
4838 content codings.
4839
4840 Content- not not not not Application/ipp
4841 Language handles language
4842
4843 Content- must- must must- must the length of the
4844 Length if if message-body per
4845 RFC 2616. Header
4846 MUST be present
4847 if Transfer-
4848 Encoding is
4849 absent..
4850
4851 Content- not not not not
4852 Location
4853
4854 Content-MD5 may may may may per RFC 2616
4855
4856 Content-Range not not not not
4857
4858 Content-Type must must must must "application/ipp"
4859 only
4860
4861 ETag not not not not
4862
4863 Expires not not not not
4864
4865 Last-Modified not not not not
4866
4867
4868
4869
4870
4871
4872
4873
4874Hastings, et al. Informational [Page 87]
4875\f
4876RFC 3196 Internet Printing Protocol/1.1 November 2001
4877
4878
48797.5 Optional support for HTTP/1.0
4880
4881 IPP implementations consist of an HTTP layer and an IPP layer. In
4882 the following discussion, the term "client" refers to the HTTP client
4883 layer and the term "server" refers to the HTTP server layer. The
4884 Encoding and Transport document [RFC2910] requires that HTTP 1.1 MUST
4885 be supported by all clients and all servers. However, a client
4886 and/or a server implementation may choose to also support HTTP 1.0.
4887
4888 This option means that a server may choose to communicate with a
4889 (non-conforming) client that only supports HTTP 1.0. In such cases
4890 the server should not use any HTTP 1.1 specific parameters or
4891 features and should respond using HTTP version number 1.0.
4892
4893 This option also means that a client may choose to communicate with a
4894 (non-conforming) server that only supports HTTP 1.0. In such cases,
4895 if the server responds with an HTTP 'unsupported version number' to
4896 an HTTP 1.1 request, the client should retry using HTTP version
4897 number 1.0.
4898
48997.6 HTTP/1.1 Chunking
4900
49017.6.1 Disabling IPP Server Response Chunking
4902
4903 Clients MUST anticipate that the HTTP/1.1 server may chunk responses
4904 and MUST accept them in responses. However, a (non-conforming) HTTP
4905 client that is unable to accept chunked responses may attempt to
4906 request an HTTP 1.1 server not to use chunking in its response to an
4907 operation by using the following HTTP header:
4908
4909 TE: identity
4910
4911 This mechanism should not be used by a server to disable a client
4912 from chunking a request, since chunking of document data is an
4913 important feature for clients to send long documents.
4914
49157.6.2 Warning About the Support of Chunked Requests
4916
4917 This section describes some problems with the use of chunked requests
4918 and HTTP/1.1 servers.
4919
4920 The HTTP/1.1 standard [RFC2616] requires that conforming servers
4921 support chunked requests for any method. However, in spite of this
4922 requirement, some HTTP/1.1 implementations support chunked responses
4923 in the GET method, but do not support chunked POST method requests.
4924 Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
4925 servlets [Servlet] require that the client supply a Content-Length.
4926 These implementations might reject a chunked POST method and return a
4927
4928
4929
4930Hastings, et al. Informational [Page 88]
4931\f
4932RFC 3196 Internet Printing Protocol/1.1 November 2001
4933
4934
4935 411 status code (Length Required), might attempt to buffer the
4936 request and run out of room returning a 413 status code (Request
4937 Entity Too Large), or might successfully accept the chunked request.
4938
4939 Because of this lack of conformance of HTTP servers to the HTTP/1.1
4940 standard, the IPP standard [RFC2910] REQUIRES that a conforming IPP
4941 Printer object implementation support chunked requests and that
4942 conforming clients accept chunked responses. Therefore, IPP object
4943 implementers are warned to seek HTTP server implementations that
4944 support chunked POST requests in order to conform to the IPP standard
4945 and/or use implementation techniques that support chunked POST
4946 requests.
4947
49488 References
4949
4950 [CGI] CGI/1.1 (http://www.w3.org/CGI/).
4951
4952 [IANA-CS] IANA Registry of Coded Character Sets:
4953 http://www.iana.org/assignments/character-sets
4954
4955 [ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald,
4956 "Internet Printing Protocol (IPP): LDAP Schema for
4957 Printer Services", Work in Progress.
4958
4959 [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
4960 RFC 793, September 1981.
4961
4962 [RFC1123] Braden, R., "Requirements for Internet Hosts -
4963 Application and Support", RFC 1123, October, 1989.
4964
4965 [RFC2026] Bradner, S., "The Internet Standards Process --
4966 Revision 3", BCP 9, RFC 2026, October 1996.
4967
4968 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4969 Requirement Levels", BCP 14, RFC 2119 , March 1997.
4970
4971 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
4972 "Uniform Resource Identifiers (URI): Generic
4973 Syntax", RFC 2396, August 1998.
4974
4975 [RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
4976 and P. Powell, "Internet Printing Protocol/1.0:
4977 Model and Semantics", RFC 2566, April 1999.
4978
4979
4980
4981
4982
4983
4984
4985
4986Hastings, et al. Informational [Page 89]
4987\f
4988RFC 3196 Internet Printing Protocol/1.1 November 2001
4989
4990
4991 [RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner,
4992 "Internet Printing Protocol/1.0: Encoding and
4993 Transport", RFC 2565, April 1999.
4994
4995 [RFC2567] Wright, D., "Design Goals for an Internet Printing
4996 Protocol", RFC 2567, April 1999.
4997
4998 [RFC2568] Zilles, S., "Rationale for the Structure and Model
4999 and Protocol for the Internet Printing Protocol",
5000 RFC 2568, April 1999.
5001
5002 [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J.
5003 Martin, "Mapping between LPD and IPP Protocols",
5004 RFC 2569, April 1999.
5005
5006 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
5007 Masinter, L., Leach, P. and T. Berners-Lee,
5008 "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616,
5009 June 1999.
5010
5011 [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner,
5012 "Internet Printing Protocol/1.0: Encoding and
5013 Transport", RFC 2910, September, 2000.
5014
5015 [RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S.
5016 and P. Powell, "Internet Printing Protocol/1.0:
5017 Model and Semantics", RFC 2911, September, 2000.
5018
5019 [Servlet] Servlet Specification Version 2.1
5020 (http://java.sun.com/products/servlet/2.1/
5021 index.html).
5022
5023 [svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I.,
5024 "Definition of the Printer Abstract Service Type
5025 v2.0", http://www.isi.edu/in-
5026 notes/iana/assignments/svrloc-
5027 templates/printer.2.0.en (IANA Registered, May 27,
5028 2000).
5029
5030 [SSL] Netscape, The SSL Protocol, Version 3, (Text
5031 version 3.02), November 1996.
5032
5033
5034
5035
5036
5037
5038
5039
5040
5041
5042Hastings, et al. Informational [Page 90]
5043\f
5044RFC 3196 Internet Printing Protocol/1.1 November 2001
5045
5046
50479. Authors' Addresses
5048
5049 Thomas N. Hastings
5050 Xerox Corporation
5051 701 Aviation Blvd.
5052 El Segundo, CA 90245
5053
5054 EMail: hastings@cp10.es.xerox.com
5055
5056
5057 Carl-Uno Manros
5058 Independent Consultant
5059 1601 N. Sepulveda Blvd. #505
5060 Manhattan Beach, CA 90266
5061
5062 Email: carl@manros.com
5063
5064
5065 Carl Kugler
5066 Mail Stop 003G
5067 IBM Printing Systems Co
5068 6300 Diagonal Hwy
5069 Boulder CO 80301
5070
5071 EMail: Kugler@us.ibm.com
5072
5073
5074 Henrik Holst
5075 i-data Printing Systems
5076 Vadstrupvej 35-43
5077 2880 Bagsvaerd, Denmark
5078
5079 EMail: hh@I-data.com
5080
5081
5082 Peter Zehler
5083 Xerox Corporation
5084 800 Philips Road
5085 Webster, NY 14580
5086
5087 EMail: PZehler@crt.xerox.com
5088
5089
5090
5091
5092
5093
5094
5095
5096
5097
5098Hastings, et al. Informational [Page 91]
5099\f
5100RFC 3196 Internet Printing Protocol/1.1 November 2001
5101
5102
5103 IPP Web Page: http://www.pwg.org/ipp/
5104 IPP Mailing List: ipp@pwg.org
5105
5106 To subscribe to the ipp mailing list, send the following email:
5107
5108 1) send it to majordomo@pwg.org
5109 2) leave the subject line blank
5110 3) put the following two lines in the message body:
5111 subscribe ipp
5112 end
5113
5114 Implementers of this specification document are encouraged to join
5115 the IPP Mailing List in order to participate in any discussions of
5116 clarification issues and review of registration proposals for
5117 additional attributes and values. In order to reduce spam the
5118 mailing list rejects mail from non-subscribers, so you must subscribe
5119 to the mailing list in order to send a question or comment to the
5120 mailing list.
5121
5122 Other Participants:
5123
5124 Chuck Adams - Tektronix Shivaun Albright - HP
5125
5126 Stefan Andersson - Axis Jeff Barnett - IBM
5127
5128 Ron Bergman - Hitachi Koki Dennis Carney - IBM
5129 Imaging Systems
5130
5131 Keith Carter - IBM Angelo Caruso - Xerox
5132
5133 Rajesh Chawla - TR Computing Nancy Chen - Okidata
5134 Solutions
5135
5136 Josh Cohen - Microsoft Jeff Copeland - QMS
5137
5138 Andy Davidson - Tektronix Roger deBry - IBM
5139
5140 Maulik Desai - Auco Mabry Dozier - QMS
5141
5142 Lee Farrell - Canon Information Satoshi Fujitami - Ricoh
5143 Systems
5144
5145 Steve Gebert - IBM Sue Gleeson - Digital
5146
5147 Charles Gordon - Osicom Brian Grimshaw - Apple
5148
5149 Jerry Hadsell - IBM Richard Hart - Digital
5150
5151
5152
5153
5154Hastings, et al. Informational [Page 92]
5155\f
5156RFC 3196 Internet Printing Protocol/1.1 November 2001
5157
5158
5159 Tom Hastings - Xerox Henrik Holst - I-data
5160
5161 Stephen Holmstead Zhi-Hong Huang - Zenographics
5162
5163 Scott Isaacson - Novell Babek Jahromi - Microsoft
5164
5165 Swen Johnson - Xerox David Kellerman - Northlake
5166 Software
5167
5168 Robert Kline - TrueSpectra Charles Kong - Panasonic
5169
5170 Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
5171
5172 Takami Kurono - Brother Rick Landau - Digital
5173
5174 Scott Lawrence - Agranot Systems Greg LeClair - Epson
5175
5176 Dwight Lewis - Lexmark Harry Lewis - IBM
5177
5178 Tony Liao - Vivid Image Roy Lomicka - Digital
5179
5180 Pete Loya - HP Ray Lutz - Cognisys
5181
5182 Mike MacKay - Novell, Inc. David Manchala - Xerox
5183
5184 Carl-Uno Manros - Xerox Jay Martin - Underscore
5185
5186 Stan McConnell - Xerox Larry Masinter - Xerox
5187
5188 Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
5189
5190 Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
5191
5192 Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
5193
5194 Pat Nogay - IBM Ron Norton - Printronics
5195
5196 Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
5197
5198 Patrick Powell - Astart Jeff Rackowitz - Intermec
5199 Technologies
5200
5201 Eric Random - Peerless Rob Rhoads - Intel
5202
5203 Xavier Riley - Xerox Gary Roberts - Ricoh
5204
5205 David Roach - Unisys Stuart Rowley - Kyocera
5206
5207
5208
5209
5210Hastings, et al. Informational [Page 93]
5211\f
5212RFC 3196 Internet Printing Protocol/1.1 November 2001
5213
5214
5215 Yuji Sasaki - Japan Computer Richard Schneider - Epson
5216 Industry
5217
5218 Kris Schoff - HP Katsuaki Sekiguchi - Canon
5219
5220 Bob Setterbo - Adobe Gail Songer - Peerless
5221
5222 Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
5223
5224 Mike Timperman - Lexmark Atsushi Uchino - Epson
5225
5226 Shigeru Ueda - Canon Bob Von Andel - Allegro Software
5227
5228 William Wagner - NetSilicon/DPI Jim Walker - DAZEL
5229
5230 Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
5231
5232 Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
5233
5234 Jasper Wong - Xionics Don Wright - Lexmark
5235
5236 Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
5237
5238 Michael Yeung - Toshiba Lloyd Young - Lexmark
5239
5240 Atsushi Yuki - Kyocera Peter Zehler - Xerox
5241
5242 William Zhang- Canon Information Frank Zhao - Panasonic
5243 Systems
5244
5245 Steve Zilles - Adobe Rob Zirnstein - Canon
5246 Information Systems
5247
524810. Description of the Base IPP Documents
5249
5250 In addition to this document, the base set of IPP documents includes:
5251
5252 Design Goals for an Internet Printing Protocol [RFC2567]
5253 Rationale for the Structure and Model and Protocol for the
5254 Internet
5255 Printing Protocol [RFC2568]
5256 Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
5257 Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
5258 Mapping between LPD and IPP Protocols [RFC2569]
5259
5260 The "Design Goals for an Internet Printing Protocol" document takes a
5261 broad look at distributed printing functionality, and it enumerates
5262 real-life scenarios that help to clarify the features that need to be
5263
5264
5265
5266Hastings, et al. Informational [Page 94]
5267\f
5268RFC 3196 Internet Printing Protocol/1.1 November 2001
5269
5270
5271 included in a printing protocol for the Internet. It identifies
5272 requirements for three types of users: end users, operators, and
5273 administrators. It calls out a subset of end user requirements that
5274 are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator
5275 operations have been added to IPP/1.1 [RFC2911, RFC2910].
5276
5277 The "Rationale for the Structure and Model and Protocol for the
5278 Internet Printing Protocol" document describes IPP from a high level
5279 view, defines a roadmap for the various documents that form the suite
5280 of IPP specification documents, and gives background and rationale
5281 for the IETF IPP working group's major decisions.
5282
5283 The "Internet Printing Protocol/1.1: Model and Semantics" document
5284 describes a simplified model with abstract objects, their attributes,
5285 and their operations. The model introduces a Printer and a Job. The
5286 Job supports multiple documents per Job. The model document also
5287 addresses how security, internationalization, and directory issues
5288 are addressed.
5289
5290 The "Internet Printing Protocol/1.1: Encoding and Transport" document
5291 is a formal mapping of the abstract operations and attributes defined
5292 in the model document onto HTTP/1.1 [RFC2616]. It also defines the
5293 encoding rules for a new Internet MIME media type called
5294 "application/ipp". This document also defines the rules for
5295 transporting a message body over HTTP whose Content-Type is
5296 "application/ipp". This document defines the 'ipp' scheme for
5297 identifying IPP printers and jobs.
5298
5299 The "Mapping between LPD and IPP Protocols" document gives some
5300 advice to implementers of gateways between IPP and LPD (Line Printer
5301 Daemon) implementations.
5302
5303
5304
5305
5306
5307
5308
5309
5310
5311
5312
5313
5314
5315
5316
5317
5318
5319
5320
5321
5322Hastings, et al. Informational [Page 95]
5323\f
5324RFC 3196 Internet Printing Protocol/1.1 November 2001
5325
5326
532711 Full Copyright Statement
5328
5329 Copyright (C) The Internet Society (2001). All Rights Reserved.
5330
5331 This document and translations of it may be copied and furnished to
5332 others, and derivative works that comment on or otherwise explain it
5333 or assist in its implementation may be prepared, copied, published
5334 and distributed, in whole or in part, without restriction of any
5335 kind, provided that the above copyright notice and this paragraph are
5336 included on all such copies and derivative works. However, this
5337 document itself may not be modified in any way, such as by removing
5338 the copyright notice or references to the Internet Society or other
5339 Internet organizations, except as needed for the purpose of
5340 developing Internet standards in which case the procedures for
5341 copyrights defined in the Internet Standards process must be
5342 followed, or as required to translate it into languages other than
5343 English.
5344
5345 The limited permissions granted above are perpetual and will not be
5346 revoked by the Internet Society or its successors or assigns.
5347
5348 This document and the information contained herein is provided on an
5349 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
5350 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
5351 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
5352 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
5353 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5354
5355Acknowledgement
5356
5357 Funding for the RFC Editor function is currently provided by the
5358 Internet Society.
5359
5360
5361
5362
5363
5364
5365
5366
5367
5368
5369
5370
5371
5372
5373
5374
5375
5376
5377
5378Hastings, et al. Informational [Page 96]
5379\f
Unnamed repository; edit this file 'description' to name the repository.