7 Network Working Group T. Hastings
8 Request for Comments: 2639 C. Manros
9 Category: Informational Xerox Corporation
13 Internet Printing Protocol/1.0: Implementer's Guide
17 This memo provides information for the Internet community. It does
18 not specify an Internet standard of any kind. Distribution of this
23 Copyright (C) The Internet Society (1999). All Rights Reserved.
27 This document is one of a set of documents, which together describe
28 all aspects of a new Internet Printing Protocol (IPP). IPP is an
29 application level protocol that can be used for distributed printing
30 using Internet tools and technologies. This document contains
31 information that supplements the IPP Model and Semantics [RFC2566]
32 and the IPP Transport and Encoding [RFC2565] documents. It is
33 intended to help implementers understand IPP/1.0 and some of the
34 considerations that may assist them in the design of their client
35 and/or IPP object implementations. For example, a typical order of
36 processing requests is given, including error checking. Motivation
37 for some of the specification decisions is also included.
39 The full set of IPP documents includes:
41 Design Goals for an Internet Printing Protocol [RFC2567]
42 Rationale for the Structure and Model and Protocol for the Internet
43 Printing Protocol [RFC2568]
44 Internet Printing Protocol/1.0: Model and Semantics [RFC2566]
45 Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]
46 Mapping between LPD and IPP Protocols [RFC2569]
48 The document, "Design Goals for an Internet Printing Protocol", takes
49 a broad look at distributed printing functionality, and it enumerates
50 real-life scenarios that help to clarify the features that need to be
51 included in a printing protocol for the Internet. It identifies
52 requirements for three types of users: end users, operators, and
58 Hastings & Manros Informational [Page 1]
60 RFC 2639 IPP/1.0: Implementer's Guide July 1999
63 administrators. The design goals document calls out a subset of end
64 user requirements that are satisfied in IPP/1.0. Operator and
65 administrator requirements are out of scope for version 1.0.
67 The document, "Rationale for the Structure and Model and Protocol for
68 the Internet Printing Protocol", describes IPP from a high level
69 view, defines a roadmap for the various documents that form the suite
70 of IPP specifications, and gives background and rationale for the
71 IETF working group's major decisions.
73 The document, "Internet Printing Protocol/1.0: Model and Semantics",
74 describes a simplified model with abstract objects, their attributes,
75 and their operations. The model introduces a Printer and a Job. The
76 Job supports multiple documents per Job. The model document also
77 addresses how security, internationalization, and directory issues
80 The document, "Internet Printing Protocol/1.0: Encoding and
81 Transport", is a formal mapping of the abstract operations and
82 attributes defined in the model document onto HTTP/1.1. It also
83 defines the encoding rules for a new Internet media type called
86 The document, "Mapping between LPD and IPP Protocols", gives some
87 advice to implementers of gateways between IPP and LPD (Line Printer
88 Daemon) implementations.
92 1 Introduction......................................................4
93 1.1 Conformance language............................................4
94 1.2 Other terminology...............................................5
95 2 Model and Semantics...............................................5
96 2.1 Summary of Operation Attributes.................................5
97 2.2 Suggested Operation Processing Steps for IPP Objects ..........10
98 2.2.1 Suggested Operation Processing Steps for all Operations..11
99 2.2.1.1 Validate version number...............................11
100 2.2.1.2 Validate operation identifier.........................11
101 2.2.1.3 Validate the request identifier.......................11
102 2.2.1.4 Validate attribute group and attribute presence and
103 order.................................................12
104 2.2.1.5 Validate the values of the REQUIRED Operation
105 attributes............................................19
106 2.2.1.6 Validate the values of the OPTIONAL Operation
107 attributes............................................23
108 2.2.2 Suggested Additional Processing Steps for Operations that
109 Create/Validate Jobs and Add Documents.....................26
110 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied......26
114 Hastings & Manros Informational [Page 2]
116 RFC 2639 IPP/1.0: Implementer's Guide July 1999
119 2.2.2.2 Check that the Printer object is accepting jobs.......26
120 2.2.2.3 Validate the values of the Job Template attributes....26
121 2.2.3 Algorithm for job validation...............................27
122 2.2.3.1 Check for conflicting Job Template attributes values..33
123 2.2.3.2 Decide whether to REJECT the request..................33
124 2.2.3.3 For the Validate-Job operation, RETURN one of the
125 success status codes..................................34
126 2.2.3.4 Create the Job object with attributes to support......34
127 2.2.3.5 Return one of the success status codes................36
128 2.2.3.6 Accept appended Document Content......................36
129 2.2.3.7 Scheduling and Starting to Process the Job............36
130 2.2.3.8 Completing the Job....................................37
131 2.2.3.9 Destroying the Job after completion...................37
132 2.2.3.10 Interaction with "ipp-attribute-fidelity".............37
133 2.3 Status codes returned by operation ............................37
134 2.3.1 Printer Operations.........................................38
135 2.3.1.1 Print-Job.............................................38
136 2.3.1.2 Print-URI.............................................40
137 2.3.1.3 Validate-Job..........................................40
138 2.3.1.4 Create-Job............................................41
139 2.3.1.5 Get-Printer-Attributes................................41
140 2.3.1.6 Get-Jobs..............................................42
141 2.3.2 Job Operations.............................................43
142 2.3.2.1 Send-Document.........................................43
143 2.3.2.2 Send-URI..............................................44
144 2.3.2.3 Cancel-Job............................................44
145 2.3.2.4 Get-Job-Attributes....................................45
146 2.4 Validate-Job...................................................46
147 2.5 Case Sensitivity in URIs ......................................46
148 2.6 Character Sets, natural languages, and internationalization....46
149 2.6.1 Character set code conversion support .....................46
150 2.6.2 What charset to return when an unsupported charset is
151 requested?.................................................48
152 2.6.3 Natural Language Override (NLO) ...........................48
153 2.7 The "queued-job-count" Printer Description attribute...........50
154 2.7.1 Why is "queued-job-count" RECOMMENDED?.....................50
155 2.7.2 Is "queued-job-count" a good measure of how busy a printer
156 is?........................................................50
157 2.8 Sending empty attribute groups ................................50
158 2.9 Returning unsupported attributes in Get-Xxxx responses ........51
159 2.10 Returning job-state in Print-Job response ....................51
160 2.11 Flow controlling the data portion of a Print-Job request .....52
161 2.12 Multi-valued attributes ......................................53
162 2.13 Querying jobs with IPP that were submitted using other job
163 submission protocols .........................................53
164 2.14 The 'none' value for empty sets ..............................54
165 2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?.........54
170 Hastings & Manros Informational [Page 3]
172 RFC 2639 IPP/1.0: Implementer's Guide July 1999
175 2.16 The "multiple-document-handling" Job Template attribute and
176 support of multiple document jobs.............................54
177 3 Encoding and Transport...........................................55
178 3.1 General Headers................................................56
179 3.2 Request Headers...............................................57
180 3.3 Response Headers...............................................58
181 3.4 Entity Headers................................................59
182 3.5 Optional support for HTTP/1.0..................................60
183 3.6 HTTP/1.1 Chunking..............................................60
184 3.6.1 Disabling IPP Server Response Chunking.....................60
185 3.6.2 Warning About the Support of Chunked Requests..............60
186 4 References.......................................................61
187 4.1 Authors' Addresses.............................................62
188 5 Security Considerations..........................................62
189 6 Notices..........................................................62
190 Full Copyright Statement............................................65
194 This document contains information that supplements the IPP Model and
195 Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565]
196 documents. As such this information is not part of the formal
197 specifications. Instead information is presented to help implementers
198 understand the specification, including some of the motivation for
199 decisions taken by the committee in developing the specification.
200 Some of the implementation considerations are intended to help
201 implementers design their client and/or IPP object implementations.
202 If there are any contradictions between this document and [RFC2566] or
203 [RFC2565], those documents take precedence over this document.
205 1.1 Conformance language
207 Usually, this document does not contain the terminology MUST, MUST
208 NOT, MAY, NEED NOT, SHOULD, SHOULD NOT, REQUIRED, and OPTIONAL.
209 However, when those terms do appear in this document, their intent is
210 to repeat what the [RFC2566] and [RFC2565] documents require and
211 allow, rather than specifying additional conformance requirements.
212 These terms are defined in section 13 on conformance terminology in
213 [RFC2566], most of which is taken from RFC 2119 [RFC2119].
215 Implementers should read section 13 in [RFC2566] in order to
216 understand these capitalized words. The words MUST, MUST NOT, and
217 REQUIRED indicate what implementations are required to support in a
218 client or IPP object in order to be conformant to [RFC2566] and
219 [RFC2565]. MAY, NEED NOT, and OPTIONAL indicate was is merely allowed
220 as an implementer option. The verbs SHOULD and SHOULD NOT indicate
221 suggested behavior, but which is not required or disallowed,
222 respectively, in order to conform to the specification.
226 Hastings & Manros Informational [Page 4]
228 RFC 2639 IPP/1.0: Implementer's Guide July 1999
231 1.2 Other terminology
233 The term "sender" refers to the client that sends a request or an IPP
234 object that returns a response. The term "receiver" refers to the IPP
235 object that receives a request and to a client that receives a
238 2 Model and Semantics
240 This section discusses various aspects of IPP/1.0 Model and Semantics
243 2.1 Summary of Operation Attributes
245 Legend for the following table:
247 R indicates a REQUIRED operation or attribute for an
248 implementation to support
250 O indicates an OPTIONAL operation or attribute for an
251 implementation to support
282 Hastings & Manros Informational [Page 5]
284 RFC 2639 IPP/1.0: Implementer's Guide July 1999
287 Table 1. Summary of operation attributes for Printer operations
293 Operation Print- Pri Crea Get- Get- All
294 Attributes Job, nt- te- Printer- Jobs Opera-
295 Validate URI Job Attribut tions
298 Operation parameters--REQUIRED to be supplied by the sender
300 operation-id R R R R R
304 request-id R R R R R R
306 version-number R R R R R R
308 Operation attributes-REQUIRED to be supplied by the sender
310 attributes-charset R R R R R R
312 attributes- R R R R R R
323 printer-uri R R R R R
325 Operation attributes-RECOMMENDED to be supplied by the sender
329 requesting-user- R R R R R
338 Hastings & Manros Informational [Page 6]
340 RFC 2639 IPP/1.0: Implementer's Guide July 1999
347 Operation Print- Pri Crea Get- Get- All
348 Attributes Job, nt- te- Printer Jobs Opera-
349 Vali- URI Job Attri- tions
350 date-Job (O) (O) butes
352 Operation attributes-OPTIONAL to be supplied by the sender
358 document-format R R O
362 document-natural- O O
368 job-impressions O O O
372 job-media-sheets O O O
385 * "job-id" is REQUIRED only if used together with
386 "printer-uri" to identify the target job; otherwise, "job-
394 Hastings & Manros Informational [Page 7]
396 RFC 2639 IPP/1.0: Implementer's Guide July 1999
399 Table 2. Summary of operation attributes for Job operations
404 Operation Send- Send- Cancel Get- All
405 Attributes Document URI -Job Job- Opera-
409 Operation parameters--REQUIRED to be supplied by the sender
417 version-number R R R R R
419 Operation attributes-REQUIRED to be supplied by the sender
421 attributes- R R R R R
424 attributes- R R R R R
437 Operation attributes-RECOMMENDED to be supplied by the
442 requesting-user- R R R R
450 Hastings & Manros Informational [Page 8]
452 RFC 2639 IPP/1.0: Implementer's Guide July 1999
459 Operation Attributes Send- Send- Cance Get- All
460 Document URI l-Job Job- Opera-
464 Operation attributes.OPTIONAL to be supplied by the sender
474 document-natural- O O
492 requested-attributes R
496 * "job-id" is REQUIRED only if used together with "printer-
497 uri" to identify the target job; otherwise, "job-uri" is
506 Hastings & Manros Informational [Page 9]
508 RFC 2639 IPP/1.0: Implementer's Guide July 1999
511 2.2 Suggested Operation Processing Steps for IPP Objects
513 This section suggests the steps and error checks that an IPP object
514 MAY perform when processing requests and returning responses. An IPP
515 object MAY perform some or all of the error checks. However, some
516 implementations MAY choose to be more forgiving than the error checks
517 shown here, in order to be able to accept requests from non-
518 conforming clients. Not performing all of these error checks is a
519 so-called "forgiving" implementation. On the other hand, clients
520 that successfully submit requests to IPP objects that do perform all
521 the error checks will be more likely to be able to interoperate with
522 other IPP object implementations. Thus an implementer of an IPP
523 object needs to decide whether to be a "forgiving" or a "strict"
524 implementation. Therefore, the error status codes returned may
525 differ between implementations. Consequentially, client SHOULD NOT
526 expect exactly the error code processing described in this section.
528 When an IPP object receives a request, the IPP object either accepts
529 or rejects the request. In order to determine whether or not to
530 accept or reject the request, the IPP object SHOULD execute the
531 following steps. The order of the steps may be rearranged and/or
532 combined, including making one or multiple passes over the request.
534 A client MUST supply requests that would pass all of the error checks
535 indicated here in order to be a conforming client. Therefore, a
536 client SHOULD supply requests that are conforming, in order to avoid
537 being rejected by some IPP object implementations and/or risking
538 different semantics by different implementations of forgiving
539 implementations. For example, a forgiving implementation that
540 accepts multiple occurrences of the same attribute, rather than
541 rejecting the request might use the first occurrences, while another
542 might use the last occurrence. Thus such a non-conforming client
543 would get different results from the two forgiving implementations.
545 In the following, processing continues step by step until a "RETURNS
546 the xxx status code ." statement is encountered. Error returns are
547 indicated by the verb: "REJECTS". Since clients have difficulty
548 getting the status code before sending all of the document data in a
549 Print-Job request, clients SHOULD use the Validate-Job operation
550 before sending large documents to be printed, in order to validate
551 whether the IPP Printer will accept the job or not.
553 It is assumed that security authentication and authorization has
554 already taken place at a lower layer.
562 Hastings & Manros Informational [Page 10]
564 RFC 2639 IPP/1.0: Implementer's Guide July 1999
567 2.2.1 Suggested Operation Processing Steps for all Operations
569 This section is intended to apply to all operations. The next
570 section contains the additional steps for the Print-Job, Validate-
571 Job, Print-URI, Create-Job, Send-Document, and Send-URI operations
572 that create jobs, adds documents, and validates jobs.
574 2.2.1.1 Validate version number
576 Every request and every response contains the "version-number"
577 attribute. The value of this attribute is the major and minor
578 version number of the syntax and semantics that the client and IPP
579 object is using, respectively. The "version-number" attribute
580 remains in a fixed position across all future versions so that all
581 clients and IPP object that support future versions can determine
582 which version is being used. The IPP object checks to see if the
583 major version number supplied in the request is supported. If not,
584 the Printer object REJECTS the request and RETURNS the 'server-
585 error-version-not-supported' status code in the response. The IPP
586 object returns in the "version-number" response attribute the major
587 and minor version for the error response. Thus the client can learn
588 at least one major and minor version that the IPP object supports.
589 The IPP object is encouraged to return the closest version number to
590 the one supplied by the client.
592 The checking of the minor version number is implementation dependent,
593 however if the client supplied minor version is explicitly supported,
594 the IPP object MUST respond using that identical minor version
595 number. If the requested minor version is not supported (the
596 requested minor version is either higher or lower) than a supported
597 minor version, the IPP object SHOULD return the closest supported
600 2.2.1.2 Validate operation identifier
602 The Printer object checks to see if the "operation-id" attribute
603 supplied by the client is supported as indicated in the Printer
604 object's "operations-supported" attribute. If not, the Printer
605 REJECTS the request and returns the 'server-error-operation-not-
606 supported' status code in the response.
608 2.2.1.3 Validate the request identifier
610 The Printer object SHOULD NOT check to see if the "request-id"
611 attribute supplied by the client is in range: between 1 and 2**31 - 1
612 (inclusive), but copies all 32 bits.
618 Hastings & Manros Informational [Page 11]
620 RFC 2639 IPP/1.0: Implementer's Guide July 1999
623 Note: The "version-number", "operation-id", and the "request-id"
624 parameters are in fixed octet positions in the IPP/1.0 encoding. The
625 "version-number" parameter will be the same fixed octet position in
626 all versions of the protocol. These fields are validated before
627 proceeding with the rest of the validation.
629 2.2.1.4 Validate attribute group and attribute presence and order
631 The order of the following validation steps depends on
634 2.2.1.4.1 Validate the presence and order of attribute groups
636 Client requests and IPP object responses contain attribute groups
637 that Section 3 requires to be present and in a specified order. An
638 IPP object verifies that the attribute groups are present and in the
639 correct order in requests supplied by clients (attribute groups
640 without an * in the following tables).
642 If an IPP object receives a request with (1) required attribute
643 groups missing, or (2) the attributes groups are out of order, or (3)
644 the groups are repeated, the IPP object REJECTS the request and
645 RETURNS the 'client-error-bad-request' status code. For example, it
646 is an error for the Job Template Attributes group to occur before the
647 Operation Attributes group, for the Operation Attributes group to be
648 omitted, or for an attribute group to occur more than once, except in
649 the Get-Jobs response.
651 Since this kind of attribute group error is most likely to be an
652 error detected by a client developer rather than by a customer, the
653 IPP object NEED NOT return an indication of which attribute group was
654 in error in either the Unsupported Attributes group or the Status
655 Message. Also, the IPP object NEED NOT find all attribute group
656 errors before returning this error.
658 2.2.1.4.2 Ignore unknown attribute groups in the expected position
660 Future attribute groups may be added to the specification at the end
661 of requests just before the Document Content and at the end of
662 response, except for the Get-Jobs response, where it maybe there or
663 before the first job attributes returned. If an IPP object receives
664 an unknown attribute group in these positions, it ignores the entire
665 group, rather than returning an error, since that group may be a new
666 group in a later minor version of the protocol that can be ignored.
667 (If the new attribute group cannot be ignored without confusing the
668 client, the major version number would have been increased in the
674 Hastings & Manros Informational [Page 12]
676 RFC 2639 IPP/1.0: Implementer's Guide July 1999
679 protocol document and in the request). If the unknown group occurs
680 in a different position, the IPP object REJECTS the request and
681 RETURNS the 'client-error-bad-request' status code.
683 Clients also ignore unknown attribute groups returned in a response.
685 Note: By validating that requests are in the proper form, IPP
686 objects force clients to use the proper form which, in turn,
687 increases the chances that customers will be able to use such clients
688 from multiple vendors with IPP objects from other vendors.
690 2.2.1.4.3 Validate the presence of a single occurrence of required
693 Client requests and IPP object responses contain Operation attributes
694 that [RFC2566] Section 3 requires to be present. Attributes within a
695 group may be in any order, except for the ordering of target,
696 charset, and natural languages attributes. These attributes MUST be
697 first, and MUST be supplied in the following order: charset, natural
698 language, and then target. An IPP object verifies that the attributes
699 that Section 4 requires to be supplied by the client have been
700 supplied in the request (attributes without an * in the following
701 tables). An asterisk (*) indicates groups and Operation attributes
702 that the client may omit in a request or an IPP object may omit in a
705 If an IPP object receives a request with required attributes missing
706 or repeated from a group or in the wrong position, the behavior of
707 the IPP object is IMPLEMENTATION DEPENDENT. Some of the possible
710 1.REJECTS the request and RETURNS the 'client-error-bad-request'
713 2.accepts the request and uses the first occurrence of the
714 attribute no matter where it is
716 3.accepts the request and uses the last occurrence of the
717 attribute no matter where it is
719 4.accept the request and assume some default value for the missing
722 Therefore, client MUST send conforming requests, if they want to
723 receive the same behavior from all IPP object implementations. For
724 example, it is an error for the "attributes-charset" or "attributes-
725 natural-language" attribute to be omitted in any operation request,
726 or for an Operation attribute to be supplied in a Job Template group
730 Hastings & Manros Informational [Page 13]
732 RFC 2639 IPP/1.0: Implementer's Guide July 1999
735 or a Job Template attribute to be supplied in an Operation Attribute
736 group in a create request. It is also an error to supply the
737 "attributes-charset" attribute twice.
739 Since these kinds of attribute errors are most likely to be detected
740 by a client developer rather than by a customer, the IPP object NEED
741 NOT return an indication of which attribute was in error in either
742 the Unsupported Attributes group or the Status Message. Also, the
743 IPP object NEED NOT find all attribute errors before returning this
746 The following tables list all the attributes for all the operations
747 by attribute group in each request and each response. The order of
748 the groups is the order that the client supplies the groups as
749 specified in [RFC2566] Section 3. The order of the attributes within
750 a group is arbitrary, except as noted for some of the special
751 operation attributes (charset, natural language, and target). The
752 tables below use the following notation:
754 R indicates a REQUIRED attribute that an IPP object MUST support
755 O indicates an OPTIONAL attribute that an IPP object NEED NOT
757 * indicates that a client MAY omit the attribute in a request
758 and that an IPP object MAY omit the attribute in a
759 response. The absence of an * means that a client MUST
760 supply the attribute in a request and an IPP object MUST
761 supply the attribute in a response.
765 The tables below show the attributes in their proper attribute groups
766 for operation requests:
768 Note: All operation requests contain "version-number", "operation-
769 id", and "request-id" parameters.
772 Group 1: Operation Attributes (R)
773 attributes-charset (R)
774 attributes-natural-language (R)
776 requesting-user-name (R*)
778 ipp-attribute-fidelity (R*)
781 document-natural-language (O*)
786 Hastings & Manros Informational [Page 14]
788 RFC 2639 IPP/1.0: Implementer's Guide July 1999
793 job-media-sheets (O*)
794 Group 2: Job Template Attributes (R*)
795 <Job Template attributes> (O*)
796 (see [RFC2566] Section 4.2)
797 Group 3: Document Content (R)
800 Validate-Job Request:
801 Group 1: Operation Attributes (R)
802 attributes-charset (R)
803 attributes-natural-language (R)
805 requesting-user-name (R*)
807 ipp-attribute-fidelity (R*)
810 document-natural-language (O*)
814 job-media-sheets (O*)
815 Group 2: Job Template Attributes (R*)
816 <Job Template attributes> (O*)
817 (see [RFC2566] Section 4.2)
820 Group 1: Operation Attributes (R)
821 attributes-charset (R)
822 attributes-natural-language (R)
824 requesting-user-name (R*)
826 ipp-attribute-fidelity (R*)
829 job-media-sheets (O*)
830 Group 2: Job Template Attributes (R*)
831 <Job Template attributes> (O*) (see
832 (see [RFC2566] Section 4.2)
835 Group 1: Operation Attributes (R)
836 attributes-charset (R)
837 attributes-natural-language (R)
842 Hastings & Manros Informational [Page 15]
844 RFC 2639 IPP/1.0: Implementer's Guide July 1999
848 requesting-user-name (R*)
850 ipp-attribute-fidelity (R*)
853 document-natural-language (O*)
857 job-media-sheets (O*)
858 Group 2: Job Template Attributes (R*)
859 <Job Template attributes> (O*) (see
860 (see [RFC2566] Section 4.2)
862 Send-Document Request:
863 Group 1: Operation Attributes (R)
864 attributes-charset (R)
865 attributes-natural-language (R)
866 (printer-uri & job-id) | job-uri (R)
868 requesting-user-name (R*)
871 document-natural-language (O*)
873 Group 2: Document Content (R*)
877 Group 1: Operation Attributes (R)
878 attributes-charset (R)
879 attributes-natural-language (R)
880 (printer-uri & job-id) | job-uri (R)
883 requesting-user-name (R*)
886 document-natural-language (O*)
898 Hastings & Manros Informational [Page 16]
900 RFC 2639 IPP/1.0: Implementer's Guide July 1999
904 Group 1: Operation Attributes (R)
905 attributes-charset (R)
906 attributes-natural-language (R)
907 (printer-uri & job-id) | job-uri (R)
908 requesting-user-name (R*)
911 Get-Printer-Attributes Request:
912 Group 1: Operation Attributes (R)
913 attributes-charset (R)
914 attributes-natural-language (R)
916 requesting-user-name (R*)
917 requested-attributes (R*)
920 Get-Job-Attributes Request:
921 Group 1: Operation Attributes (R)
922 attributes-charset (R)
923 attributes-natural-language (R)
924 (printer-uri & job-id) | job-uri (R)
925 requesting-user-name (R*)
926 requested-attributes (R*)
929 Group 1: Operation Attributes (R)
930 attributes-charset (R)
931 attributes-natural-language (R)
933 requesting-user-name (R*)
935 requested-attributes (R*)
942 The tables below show the response attributes in their proper
943 attribute groups for responses.
945 Note: All operation responses contain "version-number", "status-
946 code", and "request-id" parameters.
954 Hastings & Manros Informational [Page 17]
956 RFC 2639 IPP/1.0: Implementer's Guide July 1999
959 Send-Document Response:
961 Group 1: Operation Attributes (R)
962 attributes-charset (R)
963 attributes-natural-language (R)
965 Group 2: Unsupported Attributes (R*) (see Note 3)
966 <unsupported attributes> (R*)
967 Group 3: Job Object Attributes(R*) (see Note 2)
971 job-state-reasons (O*)
972 job-state-message (O*)
973 number-of-intervening-jobs (O*)
975 Validate-Job Response:
977 Group 1: Operation Attributes (R)
978 attributes-charset (R)
979 attributes-natural-language (R)
981 Group 2: Unsupported Attributes (R*) (see Note 3)
982 <unsupported attributes> (R*)
984 Note 2 - the Job Object Attributes and Printer Object Attributes are
985 returned only if the IPP object returns one of the success status
988 Note 3 - the Unsupported Attributes Group is present only if the
989 client included some Operation and/or Job Template attributes or
990 values that the Printer doesn't support whether a success or an error
993 Get-Printer-Attributes Response:
994 Group 1: Operation Attributes (R)
995 attributes-charset (R)
996 attributes-natural-language (R)
998 Group 2: Unsupported Attributes (R*) (see Note 4)
999 <unsupported attributes> (R*)
1000 Group 3: Printer Object Attributes(R*) (see Note 2)
1001 <requested attributes> (R*)
1003 Note 4 - the Unsupported Attributes Group is present only if the
1004 client included some Operation attributes that the Printer doesn't
1005 support whether a success or an error return.
1010 Hastings & Manros Informational [Page 18]
1012 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1015 Get-Job-Attributes Response:
1016 Group 1: Operation Attributes (R)
1017 attributes-charset (R)
1018 attributes-natural-language (R)
1020 Group 2: Unsupported Attributes (R*) (see Note 4)
1021 <unsupported attributes> (R*)
1022 Group 3: Job Object Attributes(R*) (see Note 2)
1023 <requested attributes> (R*)
1026 Group 1: Operation Attributes (R)
1027 attributes-charset (R)
1028 attributes-natural-language (R)
1030 Group 2: Unsupported Attributes (R*) (see Note 4)
1031 <unsupported attributes> (R*)
1032 Group 3: Job Object Attributes(R*) (see Note 2, 5)
1033 <requested attributes> (R*)
1035 Note 5: for the Get-Jobs operation the response contains a separate
1036 Job Object Attributes group 3 to N containing requested-attributes
1037 for each job object in the response.
1039 2.2.1.5 Validate the values of the REQUIRED Operation attributes
1041 An IPP object validates the values supplied by the client of the
1042 REQUIRED Operation attribute that the IPP object MUST support. The
1043 next section specifies the validation of the values of the OPTIONAL
1044 Operation attributes that IPP objects MAY support.
1046 The IPP object performs the following syntactic validation checks of
1047 each Operation attribute value:
1049 a)that the length of each Operation attribute value is correct for
1050 the attribute syntax tag supplied by the client according to
1051 [RFC2566] Section 4.1,
1053 b)that the attribute syntax tag is correct for that Operation
1054 attribute according to [RFC2566] Section 3,
1056 c)that the value is in the range specified for that Operation
1057 attribute according to [RFC2566] Section 3,
1059 d)that multiple values are supplied by the client only for
1060 operation attributes that are multi-valued, i.e., that are
1061 1setOf X according to [RFC2566] Section 3.
1066 Hastings & Manros Informational [Page 19]
1068 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1071 If any of these checks fail, the IPP object REJECTS the request and
1072 RETURNS the 'client-error-bad-request' or the 'client-error-request-
1073 value-too-long' status code. Since such an error is most likely to
1074 be an error detected by a client developer, rather than by an end-
1075 user, the IPP object NEED NOT return an indication of which attribute
1076 had the error in either the Unsupported Attributes Group or the
1078 Status Message. The description for each of these syntactic checks
1079 is explicitly expressed in the first IF statement in the following
1082 In addition, the IPP object checks each Operation attribute value
1083 against some Printer object attribute or some hard-coded value if
1084 there is no "xxx-supported" Printer object attribute defined. If its
1085 value is not among those supported or is not in the range supported,
1086 then the IPP object REJECTS the request and RETURNS the error status
1087 code indicated in the table by the second IF statement. If the value
1088 of the Printer object's "xxx-supported" attribute is 'no-value'
1089 (because the system administrator hasn't configured a value), the
1092 attributes-charset (charset)
1094 IF NOT a single non-empty 'charset' value, REJECT/RETURN 'client-
1097 IF the value length is greater than 63 octets, REJECT/RETURN '
1098 client-error-request-value-too-long'.
1099 IF NOT in the Printer object's "charset-supported" attribute,
1100 REJECT/RETURN "client-error-charset-not-supported".
1103 attributes-natural-language(naturalLanguage)
1105 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN
1106 'client-error-bad-request'.
1107 IF the value length is greater than 63 octets, REJECT/RETURN '
1108 client-error-request-value-too-long'.
1109 ACCEPT the request even if not a member of the set in the Printer
1110 object's "generated-natural-language-supported" attribute. If
1111 the supplied value is not a member of the Printer object's
1112 "generated-natural-language-supported" attribute, use the
1113 Printer object's "natural-language-configured" value.
1122 Hastings & Manros Informational [Page 20]
1124 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1127 requesting-user-name
1129 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1131 IF the value length is greater than 255 octets, REJECT/RETURN
1132 'client-error-request-value-too-long'.
1133 IF the IPP object can obtain a better authenticated name, use it
1139 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1141 IF the value length is greater than 255 octets, REJECT/RETURN
1142 'client-error-request-value-too-long'.
1143 IF NOT supplied by the client, the Printer object creates a name
1144 from the document-name or document-uri.
1147 document-name (name)
1149 IF NOT a single 'name' value, REJECT/RETURN 'client-error-bad-
1151 IF the value length is greater than 255 octets, REJECT/RETURN
1152 'client-error-request-value-too-long'.
1155 ipp-attribute-fidelity (boolean)
1157 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1158 REJECT/RETURN 'client-error-bad-request'.
1159 IF the value length is NOT equal to 1 octet, REJECT/RETURN '
1160 client-error-request-value-too-long'
1161 IF NOT supplied by the client, the IPP object assumes the value
1165 document-format (mimeMediaType)
1167 IF NOT a single non-empty 'mimeMediaType' value, REJECT/RETURN
1168 'client-error-bad-request'.
1169 IF the value length is greater than 255 octets, REJECT/RETURN
1170 'client-error-request-value-too-long'.
1171 IF NOT in the Printer object's "document-format-supported"
1172 attribute, REJECT/RETURN 'client-error-document-format-not-
1178 Hastings & Manros Informational [Page 21]
1180 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1183 IF NOT supplied by the client, the IPP object assumes the value of
1184 the Printer object's "document-format-default" attribute.
1189 IF NOT a single non-empty 'uri' value, REJECT/RETURN 'client-
1191 IF the value length is greater than 1023 octets, REJECT/RETURN
1192 'client-error-request-value-too-long'.
1193 IF the URI syntax is not valid, REJECT/RETURN 'client-error-bad-
1195 IF scheme is NOT in the Printer object's "reference-uri-schemes-
1196 supported" attribute, REJECT/RETURN 'client-error-uri-scheme-
1198 The Printer object MAY check to see if the document exists and is
1199 accessible. If the document is not found or is not accessible,
1200 REJECT/RETURN 'client-error-not found'.
1203 last-document (boolean)
1205 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1206 REJECT/RETURN 'client-error-bad-request'.
1207 IF the value length is NOT equal to 1 octet, REJECT/RETURN '
1208 client-error-request-value-too-long'
1211 job-id (integer(1:MAX))
1213 IF NOT an single 'integer' value equal to 4 octets AND in the
1214 range 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1216 IF NOT a job-id of an existing Job object, REJECT/RETURN 'client-
1217 error-not-found' or 'client-error-gone' status code, if keep
1218 track of recently deleted jobs.
1221 requested-attributes (1setOf keyword)
1223 IF NOT one or more 'keyword' values, REJECT/RETURN 'client-error-
1225 IF the value length is greater than 255 octets, REJECT/RETURN
1226 'client-error-request-value-too-long'.
1227 Ignore unsupported values which are the keyword names of
1228 unsupported attributes. Don't bother to copy such requested
1229 (unsupported) attributes to the Unsupported Attribute response
1230 group since the response will not return them.
1234 Hastings & Manros Informational [Page 22]
1236 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1239 which-jobs (type2 keyword)
1241 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1243 IF the value length is greater than 255 octets, REJECT/RETURN
1244 'client-error-request-value-too-long'.
1245 IF NEITHER 'completed' NOR 'not-completed', copy the attribute and
1246 the unsupported value to the Unsupported Attributes response
1247 group and REJECT/RETURN 'client-error-attributes-or-values-
1249 Note: a Printer still supports the 'completed' value even if it
1250 keeps no completed/canceled/aborted jobs: by returning no jobs
1252 IF NOT supplied by the client, the IPP object assumes the 'not-
1258 IF NEITHER a single 'true' NOR a single 'false' 'boolean' value,
1259 REJECT/RETURN 'client-error-bad-request'.
1260 IF the value length is NOT equal to 1 octet, REJECT/RETURN '
1261 client-error-request-value-too-long'
1262 IF NOT supplied by the client, the IPP object assumes the 'false'
1266 limit (integer(1:MAX))
1268 IF NOT a single 'integer' value equal to 4 octets AND in the range
1269 1 to MAX, REJECT/RETURN 'client-error-bad-request'.
1270 IF NOT supplied by the client, the IPP object returns all jobs, no
1273 2.2.1.6 Validate the values of the OPTIONAL Operation attributes
1275 OPTIONAL Operation attributes are those that an IPP object MAY or MAY
1276 NOT support. An IPP object validates the values of the OPTIONAL
1277 attributes supplied by the client. The IPP object performs the same
1278 syntactic validation checks for each OPTIONAL attribute value as in
1279 Section 2.2.1.5. As in Section 2.2.1.5, if any fail, the IPP object
1280 REJECTS the request and RETURNS the 'client-error-bad-request' or the
1281 'client-error-request-value-too-long' status code.
1283 In addition, the IPP object checks each Operation attribute value
1284 against some Printer attribute or some hard-coded value if there is
1285 no "xxx-supported" Printer attribute defined. If its value is not
1286 among those supported or is not in the range supported, then the IPP
1290 Hastings & Manros Informational [Page 23]
1292 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1295 object REJECTS the request and RETURNS the error status code
1296 indicated in the table. If the value of the Printer object's "xxx-
1297 supported" attribute is 'no-value' (because the system administrator
1298 hasn't configured a value), the check always fails.
1300 If the IPP object doesn't recognize/support an attribute, the IPP
1301 object treats the attribute as an unknown or unsupported attribute
1302 (see the last row in the table below).
1304 document-natural-language (naturalLanguage)
1306 IF NOT a single non-empty 'naturalLanguage' value, REJECT/RETURN '
1307 client-error-bad-request'.
1308 IF the value length is greater than 63 octets, REJECT/RETURN '
1309 client-error-request-value-too-long'.
1310 IF NOT a value that the Printer object supports in document
1311 formats, (no corresponding "xxx-supported" Printer attribute),
1312 REJECT/RETURN 'client-error-natural-language-not-supported'.
1315 compression (type3 keyword)
1317 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1319 IF the value length is greater than 255 octets, REJECT/RETURN '
1320 client-error-request-value-too-long'.
1321 IF NOT in the Printer object's "compression-supported" attribute,
1322 copy the attribute and the unsupported value to the Unsupported
1323 Attributes response group and REJECT/RETURN 'client-error-
1324 attributes-or-values-not-supported'.
1327 job-k-octets (integer(0:MAX))
1329 IF NOT a single 'integer' value equal to 4 octets,
1330 REJECT/RETURN 'client-error-bad-request'.
1331 IF NOT in the range of the Printer object's "job-k-octets-
1332 supported" attribute, copy the attribute and the unsupported
1333 value to the Unsupported Attributes response group and
1334 REJECT/RETURN 'client-error-attributes-or-values-not-
1338 job-impressions (integer(0:MAX))
1340 IF NOT a single 'integer' value equal to 4 octets,
1341 REJECT/RETURN 'client-error-bad-request'.
1346 Hastings & Manros Informational [Page 24]
1348 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1351 IF NOT in the range of the Printer object's "job-impressions-
1352 supported" attribute, copy the attribute and the unsupported
1353 value to the Unsupported Attributes response group and
1354 REJECT/RETURN 'client-error-attributes-or-values-not-
1358 job-media-sheets (integer(0:MAX))
1360 IF NOT a single 'integer' value equal to 4 octets,
1361 REJECT/RETURN 'client-error-bad-request'.
1362 IF NOT in the range of the Printer object's "job-media-sheets-
1363 supported" attribute, copy the attribute and the unsupported
1364 value to the Unsupported Attributes response group and
1365 REJECT/RETURN 'client-error-attributes-or-values-not-
1371 IF NOT a single 'text' value, REJECT/RETURN 'client-error-bad-
1373 IF the value length is greater than 127 octets,
1374 REJECT/RETURN 'client-error-request-value-too-long'.
1377 unknown or unsupported attribute
1379 IF the attribute syntax supplied by the client is supported but
1380 the length is not legal for that attribute syntax,
1381 REJECT/RETURN 'client-error-request-value-too-long'.
1382 ELSE copy the attribute and value to the Unsupported Attributes
1383 response group and change the attribute value to the "out-of-
1384 band" 'unsupported' value, but otherwise ignore the attribute.
1386 Note: Future Operation attributes may be added to the protocol
1387 specification that may occur anywhere in the specified group.
1388 When the operation is otherwise successful, the IPP object returns
1389 the 'successful-ok-ignored-or-substituted-attributes' status code.
1390 Ignoring unsupported Operation attributes in all operations is
1391 analogous to the handling of unsupported Job Template attributes
1392 in the create and Validate-Job operations when the client supplies
1393 the "ipp-attribute-fidelity" Operation attribute with the 'false'
1394 value. This last rule is so that we can add OPTIONAL Operation
1395 attributes to future versions of IPP so that older clients can
1396 inter-work with new IPP objects and newer clients can inter-work
1397 with older IPP objects. (If the new attribute cannot be ignored
1398 without performing unexpectedly, the major version number would
1402 Hastings & Manros Informational [Page 25]
1404 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1407 have been increased in the protocol document and in the request).
1408 This rule for Operation attributes is independent of the value of
1409 the "ipp-attribute-fidelity" attribute. For example, if an IPP
1410 object doesn't support the OPTIONAL "job-k-octets" attribute', the
1411 IPP object treats "job-k-octets" as an unknown attribute and only
1412 checks the length for the 'integer' attribute syntax supplied by
1413 the client. If it is not four octets, the IPP object REJECTS the
1414 request and RETURNS the 'client-error-bad-request' status code,
1415 else the IPP object copies the attribute to the Unsupported
1416 Attribute response group, setting the value to the "out-of-band" '
1417 unsupported' value, but otherwise ignores the attribute.
1419 2.2.2 Suggested Additional Processing Steps for Operations that
1420 Create/Validate Jobs and Add Documents
1422 This section in combination with the previous section recommends the
1423 processing steps for the Print-Job, Validate-Job, Print-URI, Create-
1424 Job, Send-Document, and Send-URI operations that IPP objects SHOULD
1425 use. These are the operations that create jobs, validate a Print-Job
1426 request, and add documents to a job.
1428 2.2.2.1 Default "ipp-attribute-fidelity" if not supplied
1430 The Printer object checks to see if the client supplied an "ipp-
1431 attribute-fidelity" Operation attribute. If the attribute is not
1432 supplied by the client, the IPP object assumes that the value is
1435 2.2.2.2 Check that the Printer object is accepting jobs
1437 If the value of the Printer object's "printer-is-accepting-jobs" is
1438 'false', the Printer object REJECTS the request and RETURNS the
1439 'server-error-not-accepting-jobs' status code.
1441 2.2.2.3 Validate the values of the Job Template attributes
1443 An IPP object validates the values of all Job Template attribute
1444 supplied by the client. The IPP object performs the analogous
1445 syntactic validation checks of each Job Template attribute value that
1446 it performs for Operation attributes (see Section 2.2.1.5.):
1448 a)that the length of each value is correct for the attribute
1449 syntax tag supplied by the client according to [RFC2566] Section
1452 b)that the attribute syntax tag is correct for that attribute
1453 according to [RFC2566] Sections 4.2 to 4.4.
1458 Hastings & Manros Informational [Page 26]
1460 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1463 c)that multiple values are supplied only for multi-valued
1464 attributes, i.e., that are 1setOf X according to [RFC2566]
1465 Sections 4.2 to 4.4.
1467 As in Section 2.2.1.5, if any of these syntactic checks fail, the IPP
1468 object REJECTS the request and RETURNS the 'client-error-bad-request'
1469 or 'client-error-request-value-too-long' status code as appropriate,
1470 independent of the value of the "ipp-attribute-fidelity". Since such
1471 an error is most likely to be an error detected by a client
1472 developer, rather than by an end-user, the IPP object NEED NOT return
1473 an indication of which attribute had the error in either the
1474 Unsupported Attributes Group or the Status Message. The description
1475 for each of these syntactic checks is explicitly expressed in the
1476 first IF statement in the following table.
1478 Each Job Template attribute MUST occur no more than once. If an IPP
1479 Printer receives a create request with multiple occurrences of a Job
1480 Template attribute, it MAY:
1482 1.reject the operation and return the 'client-error-bad syntax'
1485 2.accept the operation and use the first occurrence of the
1488 3.accept the operation and use the last occurrence of the
1491 depending on implementation. Therefore, clients MUST NOT supply
1492 multiple occurrences of the same Job Template attribute in the Job
1493 Attributes group in the request.
1495 2.2.3 Algorithm for job validation
1497 The process of validating a Job-Template attribute "xxx" against a
1498 Printer attribute "xxx-supported" can use the following validation
1499 algorithm (see section 3.2.1.2 in [RFC2566]).
1501 To validate the value U of Job-Template attribute "xxx" against the
1502 value V of Printer "xxx-supported", perform the following algorithm:
1504 1.If U is multi-valued, validate each value X of U by performing
1505 the algorithm in Table 3 with each value X. Each validation is
1506 separate from the standpoint of returning unsupported values.
1508 Example: If U is "finishings" that the client supplies with
1509 'staple', 'bind' values, then X takes on the successive values:
1510 'staple', then 'bind'
1514 Hastings & Manros Informational [Page 27]
1516 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1519 2.If V is multi-valued, validate X against each Z of V by
1520 performing the algorithm in Table 3 with each value Z. If a
1521 value Z validates, the validation for the attribute value X
1522 succeeds. If it fails, the algorithm is applied to the next
1523 value Z of V. If there are no more values Z of V, validation
1526 Example: If V is "sides-supported" with values: 'one-sided',
1527 'two-sided-long', and 'two-sided-short', then Z takes on the
1528 successive values: 'one-sided', 'two-sided-long', and
1529 'two-sided-short'. If the client supplies "sides" with 'two-
1530 sided-long', the first comparison fails ('one-sided' is not
1531 equal to 'two-sided-long'), the second comparison succeeds
1532 ('two-sided-long' is equal to 'two-sided-long"), and the third
1533 comparison ('two-sided-short' with 'two-sided-long') is not even
1536 3.If both U and V are single-valued, let X be U and Z be V and use
1537 the validation rules in Table 3.
1539 Table 3 - Rules for validating single values X against Z
1541 attribute attribute validated if:
1542 syntax of X syntax of Z
1544 integer rangeOfInteger X is within the range of
1547 uri uriScheme the uri scheme in X is
1550 any boolean the value of Z is TRUE
1552 any any X and Z are of the same
1555 If the value of the Printer object's "xxx-supported" attribute is '
1556 no-value' (because the system administrator hasn't configured a
1557 value), the check always fails. If the check fails, the IPP object
1558 copies the attribute to the Unsupported Attributes response group
1559 with its unsupported value. If the attribute contains more than one
1560 value, each value is checked and each unsupported value is separately
1561 copied, while supported values are not copied. If an IPP object
1562 doesn't recognize/support a Job Template attribute, i.e., there is no
1563 corresponding Printer object "xxx-supported" attribute, the IPP
1564 object treats the attribute as an unknown or unsupported attribute
1565 (see the last row in the table below).
1570 Hastings & Manros Informational [Page 28]
1572 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1575 If some Job Template attributes are supported for some document
1576 formats and not for others or the values are different for different
1577 document formats, the IPP object SHOULD take that into account in
1578 this validation using the value of the "document-format" supplied by
1579 the client (or defaulted to the value of the Printer's "document-
1580 format-default" attribute, if not supplied by the client). For
1581 example, if "number-up" is supported for the 'text/plain' document
1582 format, but not for the 'application/postscript' document format, the
1583 check SHOULD (though it NEED NOT) depend on the value of the
1584 "document-format" operation attribute. See "document-format" in
1585 [RFC2566] section 3.2.1.1 and 3.2.5.1.
1587 Note: whether the request is accepted or rejected is determined by
1588 the value of the "ipp-attribute-fidelity" attribute in a subsequent
1589 step, so that all Job Template attribute supplied are examined and
1590 all unsupported attributes and/or values are copied to the
1591 Unsupported Attributes response group.
1593 job-priority (integer(1:100))
1595 IF NOT a single 'integer' value with a length equal to 4 octets,
1596 REJECT/RETURN 'client-error-bad-request'.
1597 IF NOT supplied by the client, use the value of the Printer
1598 object's "job-priority-default" attribute at job submission
1600 IF NOT in the range 1 to 100, inclusive, copy the attribute and
1601 the unsupported value to the Unsupported Attributes response
1603 Map the value to the nearest supported value in the range 1:100 as
1604 specified by the number of discrete values indicated by the
1605 value of the Printer's "job-priority-supported" attribute. See
1606 the formula in [RFC2566] Section 4.2.1.
1608 job-hold-until (type3 keyword | name)
1610 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
1612 IF the value length is greater than 255 octets, REJECT/RETURN
1613 'client-error-request-value-too-long'.
1614 IF NOT supplied by the client, use the value of the Printer
1615 object's "job-hold-until" attribute at job submission time.
1616 IF NOT in the Printer object's "job-hold-until-supported"
1617 attribute, copy the attribute and the unsupported value to the
1618 Unsupported Attributes response group.
1626 Hastings & Manros Informational [Page 29]
1628 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1631 job-sheets (type3 keyword | name)
1633 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
1635 IF the value length is greater than 255 octets, REJECT/RETURN
1636 'client-error-request-value-too-long'.
1637 IF NOT in the Printer object's "job-sheets-supported" attribute,
1638 copy the attribute and the unsupported value to the Unsupported
1639 Attributes response group.
1641 multiple-document-handling (type2 keyword)
1643 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1645 IF the value length is greater than 255 octets, REJECT/RETURN
1646 'client-error-request-value-too-long'.
1647 IF NOT in the Printer object's "multiple-document-handling-
1648 supported" attribute, copy the attribute and the unsupported
1649 value to the Unsupported Attributes response group.
1651 copies (integer(1:MAX))
1653 IF NOT a single 'integer' value with a length equal to 4 octets,
1654 REJECT/RETURN 'client-error-bad-request'.
1655 IF NOT in range of the Printer object's "copies-supported"
1656 attribute copy the attribute and the unsupported value to the
1658 Attributes response group.
1660 finishings (1setOf type2 enum)
1662 IF NOT an 'enum' value(s) each with a length equal to 4 octets,
1663 REJECT/RETURN 'client-error-bad-request'.
1664 IF NOT in the Printer object's "finishings-supported" attribute,
1665 copy the attribute and the unsupported value(s), but not any
1666 supported values, to the Unsupported Attributes response group.
1668 page-ranges (1setOf rangeOfInteger(1:MAX))
1670 IF NOT a 'rangeOfInteger' value(s) each with a length equal to 8
1671 octets, REJECT/RETURN 'client-error-bad-request'.
1672 IF first value is greater than second value in any range, the
1673 ranges are not in ascending order, or ranges overlap,
1674 REJECT/RETURN 'client-error-bad-request'.
1675 IF the value of the Printer object's "page-ranges-supported"
1676 attribute is 'false', copy the attribute to the Unsupported
1677 Attributes response group and set the value to the "out-of-
1678 band" 'unsupported' value.
1682 Hastings & Manros Informational [Page 30]
1684 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1687 sides (type2 keyword)
1689 IF NOT a single 'keyword' value, REJECT/RETURN 'client-error-bad-
1691 IF the value length is greater than 255 octets, REJECT/RETURN
1692 'client-error-request-value-too-long'.
1693 IF NOT in the Printer object's "sides-supported" attribute, copy
1694 the attribute and the unsupported value to the Unsupported
1695 Attributes response group.
1697 number-up (integer(1:MAX))
1699 IF NOT a single 'integer' value with a length equal to 4 octets,
1700 REJECT/RETURN 'client-error-bad-request'.
1701 IF NOT a value or in the range of one of the values of the Printer
1702 object's "number-up-supported" attribute, copy the attribute
1703 and value to the Unsupported Attribute response group.
1705 orientation-requested (type2 enum)
1707 IF NOT a single 'enum' value with a length equal to 4 octets,
1708 REJECT/RETURN 'client-error-bad-request'.
1709 IF NOT in the Printer object's "orientation-requested-supported"
1710 attribute, copy the attribute and the unsupported value to the
1711 Unsupported Attributes response group.
1713 media (type3 keyword | name)
1715 IF NOT a single 'keyword' or 'name' value, REJECT/RETURN 'client-
1717 IF the value length is greater than 255 octets, REJECT/RETURN
1718 'client-error-request-value-too-long'.
1719 IF NOT in the Printer object's "media-supported" attribute, copy
1720 the attribute and the unsupported value to the Unsupported
1721 Attributes response group.
1723 printer-resolution (resolution)
1725 IF NOT a single 'resolution' value with a length equal to 9
1727 REJECT/RETURN 'client-error-bad-request'.
1728 IF NOT in the Printer object's "printer-resolution-supported"
1729 attribute, copy the attribute and the unsupported value to the
1730 Unsupported Attributes response group.
1738 Hastings & Manros Informational [Page 31]
1740 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1743 print-quality (type2 enum)
1745 IF NOT a single 'enum' value with a length equal to 4 octets,
1746 REJECT/RETURN 'client-error-bad-request'.
1747 IF NOT in the Printer object's "print-quality-supported"
1748 attribute, copy the attribute and the unsupported value to the
1749 Unsupported Attributes response group.
1751 unknown or unsupported attribute (i.e., there is no corresponding
1752 Printer object "xxx-supported" attribute)
1754 IF the attribute syntax supplied by the client is supported but
1755 the length is not legal for that attribute syntax,
1756 REJECT/RETURN 'client-error-bad-request' if the length of the
1757 attribute syntax is fixed or 'client-error-request-value-too-
1758 long' if the length of the attribute syntax is variable.
1759 ELSE copy the attribute and value to the Unsupported Attributes
1760 response group and change the attribute value to the "out-of-
1761 band" 'unsupported' value. Any remaining Job Template
1762 Attributes are either unknown or unsupported Job Template
1763 attributes and are validated algorithmically according to their
1764 attribute syntax for proper length (see below).
1766 If the attribute syntax is supported AND the length check
1767 fails, the IPP object REJECTS the request and RETURNS the '
1768 client-error-bad-request' if the length of the attribute syntax
1769 is fixed or the 'client-error-request-value-too-long' status
1770 code if the length of the attribute syntax is variable.
1771 Otherwise, the IPP object copies the unsupported Job Template
1772 attribute to the Unsupported Attributes response group and
1773 changes the attribute value to the "out-of-band" 'unsupported'
1774 value. The following table shows the length checks for all
1775 attribute syntaxes. In the following table: "<=" means less
1776 than or equal, "=" means equal to:
1778 Name Octet length check for read-write attributes
1779 ----------- --------------------------------------------
1780 'textWithLanguage <= 1023 AND 'naturalLanguage' <= 63
1781 'textWithoutLanguage' <= 1023
1782 'nameWithLanguage' <= 255 AND 'naturalLanguage' <= 63
1783 'nameWithoutLanguage' <= 255
1789 'naturalLanguage' <= 63
1790 'mimeMediaType' <= 255
1794 Hastings & Manros Informational [Page 32]
1796 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1799 'octetString' <= 1023
1802 'rangeOfInteger' = 8
1807 2.2.3.1 Check for conflicting Job Template attributes values
1809 Once all the Operation and Job Template attributes have been checked
1810 individually, the Printer object SHOULD check for any conflicting
1811 values among all the supported values supplied by the client. For
1812 example, a Printer object might be able to staple and to print on
1813 transparencies, however due to physical stapling constraints, the
1814 Printer object might not be able to staple transparencies. The IPP
1815 object copies the supported attributes and their conflicting
1816 attribute values to the Unsupported Attributes response group. The
1817 Printer object only copies over those attributes that the Printer
1818 object either ignores or substitutes in order to resolve the
1819 conflict, and it returns the original values which were supplied by
1820 the client. For example suppose the client supplies "finishings"
1821 equals 'staple' and "media" equals 'transparency', but the Printer
1822 object does not support stapling transparencies. If the Printer
1823 chooses to ignore the stapling request in order to resolve the
1824 conflict, the Printer objects returns "finishings" equal to 'staple'
1825 in the Unsupported Attributes response group. If any attributes are
1826 multi-valued, only the conflicting values of the attributes are
1829 Note: The decisions made to resolve the conflict (if there is a
1830 choice) is implementation dependent.
1832 2.2.3.2 Decide whether to REJECT the request
1834 If there were any unsupported Job Template attributes or
1835 unsupported/conflicting Job Template attribute values and the client
1836 supplied the "ipp-attribute-fidelity" attribute with the 'true'
1837 value, the Printer object REJECTS the request and return the status
1840 (1) 'client-error-conflicting-attributes' status code, if there
1841 were any conflicts between attributes supplied by the client.
1842 (2) 'client-error-attributes-or-values-not-supported' status code,
1850 Hastings & Manros Informational [Page 33]
1852 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1855 Note: Unsupported Operation attributes or values that are returned
1856 do not affect the status returned in this step. If the unsupported
1857 Operation attribute was a serious error, the above already rejected
1858 the request in a previous step. If control gets to this step with
1859 unsupported Operation attributes being returned, they are not serious
1862 2.2.3.3 For the Validate-Job operation, RETURN one of the success
1865 If the requested operation is the Validate-Job operation, the Printer
1868 (1) the "successful-ok" status code, if there are no unsupported
1869 or conflicting Job Template attributes or values.
1870 (2) the "successful-ok-conflicting-attributes, if there are any
1871 conflicting Job Template attribute or values.
1872 (3) the "successful-ok-ignored-or-substituted-attributes, if there
1873 are only unsupported Job Template attributes or values.
1875 Note: Unsupported Operation attributes or values that are returned
1876 do not affect the status returned in this step. If the unsupported
1877 Operation attribute was a serious error, the above already rejected
1878 the request in a previous step. If control gets to this step with
1879 unsupported Operation attributes being returned, they are not serious
1882 2.2.3.4 Create the Job object with attributes to support
1884 If "ipp-attribute-fidelity" is set to 'false' (or it was not supplied
1885 by the client), the Printer object:
1887 (1) creates a Job object, assigns a unique value to the job's
1888 "job-uri" and "job-id" attributes, and initializes all of the
1889 job's other supported Job Description attributes.
1890 (2) removes all unsupported attributes from the Job object.
1891 (3) for each unsupported value, removes either the unsupported
1892 value or substitutes the unsupported attribute value with some
1893 supported value. If an attribute has no values after removing
1894 unsupported values from it, the attribute is removed from the
1895 Job object (so that the normal default behavior at job
1896 processing time will take place for that attribute).
1897 (4) for each conflicting value, removes either the conflicting
1898 value or substitutes the conflicting attribute value with some
1899 other supported value. If an attribute has no values after
1900 removing conflicting values from it, the attribute is removed
1901 from the Job object (so that the normal default behavior at
1902 job processing time will take place for that attribute).
1906 Hastings & Manros Informational [Page 34]
1908 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1911 If there were no attributes or values flagged as unsupported, or the
1912 value of 'ipp-attribute-fidelity" was 'false', the Printer object is
1913 able to accept the create request and create a new Job object. If
1914 the "ipp-attribute-fidelity" attribute is set to 'true', the Job
1915 Template attributes that populate the new Job object are necessarily
1916 all the Job Template attributes supplied in the create request. If
1917 the "ipp-attribute-fidelity" attribute is set to 'false', the Job
1918 Template attributes that populate the new Job object are all the
1919 client supplied Job Template attributes that are supported or that
1920 have value substitution. Thus, some of the requested Job Template
1921 attributes may not appear in the Job object because the Printer
1922 object did not support those attributes. The attributes that
1923 populate the Job object are persistently stored with the Job object
1924 for that Job. A Get-Job-Attributes operation on that Job object will
1925 return only those attributes that are persistently stored with the
1928 Note: All Job Template attributes that are persistently stored with
1929 the Job object are intended to be "override values"; that is, they
1930 that take precedence over whatever other embedded instructions might
1931 be in the document data itself. However, it is not possible for all
1932 Printer objects to realize the semantics of "override". End users
1933 may query the Printer's "pdl-override-supported" attribute to
1934 determine if the Printer either attempts or does not attempt to
1935 override document data instructions with IPP attributes.
1937 There are some cases, where a Printer supports a Job Template
1938 attribute and has an associated default value set for that attribute.
1939 In the case where a client does not supply the corresponding
1940 attribute, the Printer does not use its default values to populate
1941 Job attributes when creating the new Job object; only Job Template
1942 attributes actually in the create request are used to populate the
1943 Job object. The Printer's default values are only used later at Job
1944 processing time if no other IPP attribute or instruction embedded in
1945 the document data is present.
1947 Note: If the default values associated with Job Template attributes
1948 that the client did not supply were to be used to populate the Job
1949 object, then these values would become "override values" rather than
1950 defaults. If the Printer supports the 'attempted' value of the
1951 "pdl-override-supported" attribute, then these override values could
1952 replace values specified within the document data. This is not the
1953 intent of the default value mechanism. A default value for an
1954 attribute is used only if the create request did not specify that
1955 attribute (or it was ignored when allowed by "ipp-attribute-fidelity"
1956 being 'false') and no value was provided within the content of the
1962 Hastings & Manros Informational [Page 35]
1964 RFC 2639 IPP/1.0: Implementer's Guide July 1999
1967 If the client does not supply a value for some Job Template
1968 attribute, and the Printer does not support that attribute, as far as
1969 IPP is concerned, the result of processing that Job (with respect to
1970 the missing attribute) is undefined.
1972 2.2.3.5 Return one of the success status codes
1974 Once the Job object has been created, the Printer object accepts the
1975 request and returns to the client:
1977 (1) the 'successful-ok' status code, if there are no unsupported
1978 or conflicting Job Template attributes or values.
1979 (2) the 'successful-ok-conflicting-attributes' status code, if
1980 there are any conflicting Job Template attribute or values.
1981 (3) the 'successful-ok-ignored-or-substituted-attributes' status
1982 code, if there are only unsupported Job Template attributes or
1985 Note: Unsupported Operation attributes or values that are returned
1986 do not affect the status returned in this step. If the unsupported
1987 Operation attribute was a serious error, the above already rejected
1988 the request in a previous step. If control gets to this step with
1989 unsupported Operation attributes being returned, they are not serious
1992 The Printer object also returns Job status attributes that indicate
1993 the initial state of the Job ('pending', 'pending-held', '
1994 processing', etc.), etc. See Print-Job Response, [RFC2566] section
1997 2.2.3.6 Accept appended Document Content
1999 The Printer object accepts the appended Document Content data and
2000 either starts it printing, or spools it for later processing.
2002 2.2.3.7 Scheduling and Starting to Process the Job
2004 The Printer object uses its own configuration and implementation
2005 specific algorithms for scheduling the Job in the correct processing
2006 order. Once the Printer object begins processing the Job, the
2007 Printer changes the Job's state to 'processing'. If the Printer
2008 object supports PDL override (the "pdl-override-supported" attribute
2009 set to 'attempted'), the implementation does its best to see that IPP
2010 attributes take precedence over embedded instructions in the document
2018 Hastings & Manros Informational [Page 36]
2020 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2023 2.2.3.8 Completing the Job
2025 The Printer object continues to process the Job until it can move the
2026 Job into the 'completed' state. If an Cancel-Job operation is
2027 received, the implementation eventually moves the Job into the '
2028 canceled' state. If the system encounters errors during processing
2029 that do not allow it to progress the Job into a completed state, the
2030 implementation halts all processing, cleans up any resources, and
2031 moves the Job into the 'aborted' state.
2033 2.2.3.9 Destroying the Job after completion
2035 Once the Job moves to the 'completed', 'aborted', or 'canceled'
2036 state, it is an implementation decision as to when to destroy the Job
2037 object and release all associated resources. Once the Job has been
2038 destroyed, the Printer would return either the "client-error-not-
2039 found" or "client-error-gone" status codes for operations directed at
2042 Note: the Printer object SHOULD NOT re-use a "job-uri" or "job-id"
2043 value for a sufficiently long time after a job has been destroyed, so
2044 that stale references kept by clients are less likely to access the
2047 2.2.3.10 Interaction with "ipp-attribute-fidelity"
2049 Some Printer object implementations may support "ipp-attribute-
2050 fidelity" set to 'true' and "pdl-override-supported" set to '
2051 attempted' and yet still not be able to realize exactly what the
2052 client specifies in the create request. This is due to legacy
2053 decisions and assumptions that have been made about the role of job
2054 instructions embedded within the document data and external job
2055 instructions that accompany the document data and how to handle
2056 conflicts between such instructions. The inability to be 100%
2057 precise about how a given implementation will behave is also
2058 compounded by the fact that the two special attributes, "ipp-
2059 attribute-fidelity" and "pdl-override-supported", apply to the whole
2060 job rather than specific values for each attribute. For example, some
2061 implementations may be able to override almost all Job Template
2062 attributes except for "number-up".
2064 2.3 Status codes returned by operation
2066 This section lists all status codes once in the first operation
2067 (Print-Job). Then it lists the status codes that are different or
2068 specialized for subsequent operations under each operation.
2074 Hastings & Manros Informational [Page 37]
2076 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2079 2.3.1 Printer Operations
2083 The Printer object MUST return one of the following "status-code"
2084 values for the indicated reason. Whether all of the document data
2085 has been accepted or not before returning the success or error
2086 response depends on implementation. See Section 14 for a more
2087 complete description of each status code.
2089 For the following success status codes, the Job object has been
2090 created and the "job-id", and "job-uri" assigned and returned in the
2093 successful-ok: no request attributes were substituted or ignored.
2094 successful-ok-ignored-or-substituted-attributes: some supplied
2095 (1) attributes were ignored or (2) unsupported attribute
2096 syntaxes or values were substituted with supported values or
2097 were ignored. Unsupported attributes, attribute syntaxes, or
2098 values MUST be returned in the Unsupported Attributes group of
2100 successful-ok-conflicting-attributes: some supplied attribute
2101 values conflicted with the values of other supplied attributes
2102 and were either substituted or ignored. Attributes or values
2103 which conflict with other attributes and have been substituted
2104 or ignored MUST be returned in the Unsupported Attributes group
2105 of the response as supplied by the client.
2107 [RFC2566] section 3.1.6 Operation Status Codes and Messages states:
2109 If the Printer object supports the "status-message" operation
2110 attribute, it SHOULD use the REQUIRED 'utf-8' charset to return
2111 a status message for the following error status codes (see
2112 section 14): 'client-error-bad-request', 'client-error-
2113 charset-not-supported', 'server-error-internal-error', '
2114 server-error-operation-not-supported', and 'server-error-
2115 version-not-supported'. In this case, it MUST set the value of
2116 the "attributes-charset" operation attribute to 'utf-8' in the
2119 For the following error status codes, no job is created and no "job-
2120 id" or "job-uri" is returned:
2122 client-error-bad-request: The request syntax does not conform to
2130 Hastings & Manros Informational [Page 38]
2132 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2135 client-error-forbidden: The request is being refused for
2136 authorization or authentication reasons. The implementation
2137 security policy is to not reveal whether the failure is one of
2138 authentication or authorization.
2139 client-error-not-authenticated: Either the request requires
2140 authentication information to be supplied or the authentication
2141 information is not sufficient for authorization.
2142 client-error-not-authorized: The requester is not authorized to
2143 perform the request on the target object.
2144 client-error-not-possible: The request cannot be carried out
2145 because of the state of the system. See also 'server-error-
2146 not-accepting-jobs' status code which MUST take precedence if
2147 the Printer object's "printer-accepting-jobs" attribute is '
2149 client-error-timeout: not applicable.
2150 client-error-not-found: the target object does not exist.
2151 client-error-gone: the target object no longer exists and no
2152 forwarding address is known.
2153 client-error-request-entity-too-large: the size of the request
2154 and/or print data exceeds the capacity of the IPP Printer to
2156 client-error-request-value-too-long: the size of request variable
2157 length attribute values, such as 'text' and 'name' attribute
2158 syntaxes, exceed the maximum length specified in [RFC2566] for
2159 the attribute and MUST be returned in the Unsupported
2161 client-error-document-format-not-supported: the document format
2162 supplied is not supported. The "document-format" attribute
2163 with the unsupported value MUST be returned in the Unsupported
2164 Attributes Group. This error SHOULD take precedence over any
2165 other 'xxx-not-supported' error, except 'client-error-charset-
2167 client-error-attributes-or-values-not-supported: one or more
2168 supplied attributes, attribute syntaxes, or values are not
2169 supported and the client supplied the "ipp-attributes-fidelity"
2170 operation attribute with a 'true' value. They MUST be returned
2171 in the Unsupported Attributes Group as explained below.
2172 client-error-uri-scheme-not-supported: not applicable.
2173 client-error-charset-not-supported: the charset supplied in the
2174 "attributes-charset" operation attribute is not supported. The
2175 Printer's "configured-charset" MUST be returned in the response
2176 as the value of the "attributes-charset" operation attribute
2177 and used for any 'text' and 'name' attributes returned in the
2178 error response. This error SHOULD take precedence over any
2179 other error, unless the request syntax is so bad that the
2180 client's supplied "attributes-charset" cannot be determined.
2186 Hastings & Manros Informational [Page 39]
2188 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2191 client-error-conflicting-attributes: one or more supplied
2192 attribute va attribute values conflicted with each other and
2193 the client supplied the "ipp-attributes-fidelity" operation
2194 attribute with a 'true' value. They MUST be returned in the
2195 Unsupported Attributes Group as explained below.
2196 server-error-internal-error: an unexpected condition prevents the
2197 request from being fulfilled.
2198 server-error-operation-not-supported: not applicable (since
2199 Print-Job is REQUIRED).
2200 server-error-service-unavailable: the service is temporarily
2202 server-error-version-not-supported: the version in the request is
2203 not supported. The "closest" version number supported MUST be
2204 returned in the response.
2205 server-error-device-error: a device error occurred while
2206 receiving or spooling the request or document data or the IPP
2207 Printer object can only accept one job at a time.
2208 server-error-temporary-error: a temporary error such as a buffer
2209 full write error, a memory overflow, or a disk full condition
2210 occurred while receiving the request and/or the document data.
2211 server-error-not-accepting-jobs: the Printer object's "printer-
2212 is-not-accepting-jobs" attribute is 'false'.
2213 server-error-busy: the Printer is too busy processing jobs to
2214 accept another job at this time.
2215 server-error-job-canceled: the job has been canceled by an
2216 operator or the system while the client was transmitting the
2221 All of the Print-Job status codes described in Section 3.2.1.2
2222 Print-Job Response are applicable to Print-URI with the following
2223 specializations and differences. See Section 14 for a more complete
2224 description of each status code.
2226 server-error-uri-scheme-not-supported: the URI scheme supplied in
2227 the "document-uri" operation attribute is not supported and is
2228 returned in the Unsupported Attributes group.
2230 2.3.1.3 Validate-Job
2232 All of the Print-Job status codes described in Section 3.2.1.2
2233 Print-Job Response are applicable to Validate-Job. See Section 14
2234 for a more complete description of each status code.
2242 Hastings & Manros Informational [Page 40]
2244 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2249 All of the Print-Job status codes described in Section 3.2.1.2
2250 Print-Job Response are applicable to Create-Job with the following
2251 specializations and differences. See Section 14 for a more complete
2252 description of each status code.
2254 server-error-operation-not-supported: the Create-Job operation is
2257 2.3.1.5 Get-Printer-Attributes
2259 All of the Print-Job status codes described in Section 3.2.1.2
2260 Print-Job Response are applicable to the Get-Printer-Attributes
2261 operation with the following specializations and differences. See
2262 Section 14 for a more complete description of each status code.
2264 For the following success status codes, the requested attributes are
2265 returned in Group 3 in the response:
2267 successful-ok: no request attributes were substituted or ignored
2268 (same as Print-Job) and no requested attributes were
2270 successful-ok-ignored-or-substituted-attributes: same as Print-
2271 Job, except the "requested-attributes" operation attribute MAY,
2272 but NEED NOT, be returned with the unsupported values.
2273 successful-ok-conflicting-attributes: same as Print-Job.
2275 For the error status codes, Group 3 is returned containing no
2276 attributes or is not returned at all:
2278 client-error-not-possible: Same as Print-Job, in addition the
2279 Printer object is not accepting any requests.
2280 client-error-request-entity-too-large: same as Print-job, except
2281 that no print data is involved.
2282 client-error-attributes-or-values-not-supported: not applicable,
2283 since unsupported operation attributes MUST be ignored and '
2284 successful-ok-ignored-or-substituted-attributes' returned.
2285 client-error-conflicting-attributes: same as Print-Job, except
2286 that "ipp-attribute-fidelity" is not involved.
2287 server-error-operation-not-supported: not applicable (since Get-
2288 Printer-Attributes is REQUIRED).
2289 server-error-device-error: same as Print-Job, except that no
2290 document data is involved.
2291 server-error-temporary-error: same as Print-Job, except that no
2292 document data is involved.
2293 server-error-not-accepting-jobs: not applicable.
2298 Hastings & Manros Informational [Page 41]
2300 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2303 server-error-busy: same as Print-Job, except the IPP object is
2304 too busy to accept even query requests.
2305 server-error-job-canceled: not applicable.
2309 All of the Print-Job status codes described in Section 3.2.1.2
2310 Print-Job Response are applicable to the Get-Jobs operation with the
2311 following specializations and differences. See Section 14 for a
2312 more complete description of each status code.
2314 For the following success status codes, the requested attributes are
2315 returned in Group 3 in the response:
2317 successful-ok: no request attributes were substituted or ignored
2318 (same as Print-Job) and no requested attributes were
2320 successful-ok-ignored-or-substituted-attributes: same as Print-
2321 Job, except the "requested-attributes" operation attribute MAY,
2322 but NEED NOT, be returned with the unsupported values.
2323 successful-ok-conflicting-attributes: same as Print-Job.
2325 For any error status codes, Group 3 is returned containing no
2326 attributes or is not returned at all. The following brief error
2327 status code descriptions contain unique information for use with
2328 Get-Jobs operation. See section 14 for the other error status codes
2329 that apply uniformly to all operations:
2331 client-error-not-possible: Same as Print-Job, in addition the
2332 Printer object is not accepting any requests.
2333 client-error-request-entity-too-large: same as Print-job, except
2334 that no print data is involved.
2335 client-error-document-format-not-supported: not applicable.
2336 client-error-attributes-or-values-not-supported: not applicable,
2337 since unsupported operation attributes MUST be ignored and '
2338 successful-ok-ignored-or-substituted-attributes' returned.
2339 client-error-conflicting-attributes: same as Print-Job, except
2340 that "ipp-attribute-fidelity" is not involved.
2341 server-error-operation-not-supported: not applicable (since Get-
2343 server-error-device-error: same as Print-Job, except that no
2344 document data is involved.
2345 server-error-temporary-error: same as Print-Job, except that no
2346 document data is involved.
2347 server-error-not-accepting-jobs: not applicable.
2348 server-error-job-canceled: not applicable.
2354 Hastings & Manros Informational [Page 42]
2356 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2359 2.3.2 Job Operations
2361 2.3.2.1 Send-Document
2363 All of the Print-Job status codes described in Section 3.2.1.2
2364 Print-Job Response are applicable to the Get-Printer-Attributes
2365 operation with the following specializations and differences. See
2366 Section 14 for a more complete description of each status code.
2368 For the following success status codes, the document has been added
2369 to the specified Job object and the job's "number-of-documents"
2370 attribute has been incremented:
2372 successful-ok: no request attributes were substituted or ignored
2373 (same as Print-Job).
2374 successful-ok-ignored-or-substituted-attributes: same as Print-
2376 successful-ok-conflicting-attributes: same as Print-Job.
2378 For the error status codes, no document has been added to the Job
2379 object and the job's "number-of-documents" attribute has not been
2382 client-error-not-possible: Same as Print-Job, except that the
2383 Printer's "printer-is-accepting-jobs" attribute is not
2384 involved, so that the client is able to finish submitting a
2385 multi-document job after this attribute has been set to 'true'.
2386 Another condition is that the state of the job precludes Send-
2387 Document, i.e., the job has already been closed out by the
2388 client. However, if the IPP Printer closed out the job due to
2389 timeout, the 'client-error-timeout' error status SHOULD be
2391 client-error-timeout: This request was sent after the Printer
2392 closed the job, because it has not received a Send-Document or
2393 Send-URI operation within the Printer's "multiple-operation-
2395 client-error-request-entity-too-large: same as Print-Job.
2396 client-error-conflicting-attributes: same as Print-Job, except
2397 that "ipp-attributes-fidelity" operation attribute is not
2399 server-error-operation-not-supported: the Send-Document request
2401 server-error-not-accepting-jobs: not applicable.
2402 server-error-job-canceled: the job has been canceled by an
2403 operator or the system while the client was transmitting the
2410 Hastings & Manros Informational [Page 43]
2412 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2417 All of the Print-Job status code descriptions in Section 3.2.1.2
2418 Print-Job Response with the specializations described for Send-
2419 Document are applicable to Send-URI. See Section 14 for a more
2420 complete description of each status code.
2422 server-error-uri-scheme-not-supported: the URI scheme supplied in
2423 the "document-uri" operation attribute is not supported and the
2424 "document-uri" attribute MUST be returned in the Unsupported
2429 All of the Print-Job status codes described in Section 3.2.1.2
2430 Print-Job Response are applicable to Cancel-Job with the following
2431 specializations and differences. See Section 14 for a more complete
2432 description of each status code.
2434 For the following success status codes, the Job object is being
2435 canceled or has been canceled:
2437 successful-ok: no request attributes were substituted or ignored
2438 (same as Print-Job).
2439 successful-ok-ignored-or-substituted-attributes: same as Print-
2441 successful-ok-conflicting-attributes: same as Print-Job.
2443 For any of the error status codes, the Job object has not been
2444 canceled or was previously canceled.
2446 client-error-not-possible: The request cannot be carried out
2447 because of the state of the Job object ('completed', '
2448 canceled', or 'aborted') or the state of the system.
2449 client-error-not-found: the target Printer and/or Job object does
2451 client-error-gone: the target Printer and/or Job object no longer
2452 exists and no forwarding address is known.
2453 client-error-request-entity-too-large: same as Print-Job, except
2454 no document data is involved.
2455 client-error-document-format-not-supported: not applicable.
2456 client-error-attributes-or-values-not-supported: not applicable,
2457 since unsupported operation attributes and values MUST be
2459 client-error-conflicting-attributes: same as Print-Job, except
2460 that the Printer's "printer-is-accepting-jobs" attribute is not
2466 Hastings & Manros Informational [Page 44]
2468 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2471 server-error-operation-not-supported: not applicable (Cancel-Job
2473 server-error-device-error: same as Print-Job, except no document
2475 server-error-temporary-error: same as Print-Job, except no
2476 document data is involved.
2477 server-error-not-accepting-jobs: not applicable.
2478 server-error-job-canceled: not applicable.
2480 2.3.2.4 Get-Job-Attributes
2482 All of the Print-Job status codes described in Section 3.2.1.2
2483 Print-Job Response are applicable to Get-Job-Attributes with the
2484 following specializations and differences. See Section 14 for a more
2485 complete description of each status code.
2487 For the following success status codes, the requested attributes are
2488 returned in Group 3 in the response:
2490 successful-ok: no request attributes were substituted or ignored
2491 (same as Print-Job) and no requested attributes were
2493 successful-ok-ignored-or-substituted-attributes: same as Print-
2494 Job, except the "requested-attributes" operation attribute MAY,
2495 but NEED NOT, be returned with the unsupported values.
2496 successful-ok-conflicting-attributes: same as Print-Job.
2498 For the error status codes, Group 3 is returned containing no
2499 attributes or is not returned at all.
2501 client-error-not-possible: Same as Print-Job, in addition the
2502 Printer object is not accepting any requests.
2503 client-error-document-format-not-supported: not applicable.
2504 client-error-attributes-or-values-not-supported: not applicable.
2505 client-error-uri-scheme-not-supported: not applicable.
2506 client-error-conflicting-attributes: not applicable
2507 server-error-operation-not-supported: not applicable (since Get-
2508 Job-Attributes is REQUIRED).
2509 server-error-device-error: same as Print-Job, except no document
2511 server-error-temporary-error: sane as Print-Job, except no
2512 document data is involved.
2513 server-error-not-accepting-jobs: not applicable. server-error-
2514 job-canceled: not applicable.
2522 Hastings & Manros Informational [Page 45]
2524 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2529 The Validate-Job operation has been designed so that its
2530 implementation may be a part of the Print-Job operation. Therefore,
2531 requiring Validate-Job is not a burden on implementers. Also it is
2532 useful for client's to be able to count on its presence in all
2533 conformance implementations, so that the client can determine before
2534 sending a long document, whether the job will be accepted by the IPP
2537 2.5 Case Sensitivity in URIs
2539 IPP client and server implementations must be aware of the diverse
2540 uppercase/lowercase nature of URIs. RFC 2396 defines URL schemes and
2541 Host names as case insensitive but reminds us that the rest of the
2542 URL may well demonstrate case sensitivity. When creating URL's for
2543 fields where the choice is completely arbitrary, it is probably best
2544 to select lower case. However, this cannot be guaranteed and
2545 implementations MUST NOT rely on any fields being case-sensitive or
2546 case-insensitive in the URL beyond the URL scheme and host name
2549 The reason that the IPP specification does not make any restrictions
2550 on URIs, is so that implementations of IPP may use off-the-shelf
2551 components that conform to the standards that define URIs, such as
2552 RFC 2396 and the HTTP/1.1 specifications [RFC2068]. See these
2553 specifications for rules of matching, comparison, and case-
2556 It is also recommended that System Administrators and implementations
2557 avoid creating URLs for different printers that differ only in their
2558 case. For example, don't have Printer1 and printer1 as two different
2561 The HTTP/1.1 specification [RFC2068] contains more details on
2564 2.6 Character Sets, natural languages, and internationalization
2566 This section discusses character set support, natural language
2567 support and internationalization.
2569 2.6.1 Character set code conversion support
2571 IPP clients and IPP objects are REQUIRED to support UTF-8. They MAY
2572 support additional charsets. It is RECOMMENDED that an IPP object
2573 also support US-ASCII, since many clients support US-ASCII, and
2574 indicate that UTF-8 and US-ASCII are supported by populating the
2578 Hastings & Manros Informational [Page 46]
2580 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2583 Printer's "charset-supported" with 'utf-8' and 'us-ascii' values. An
2584 IPP object is required to code covert with as little loss as possible
2585 between the charsets that it supports, as indicated in the Printer's
2586 "charsets-supported" attribute.
2588 How should the server handle the situation where the "attributes-
2589 charset" of the response itself is "us-ascii", but one or more
2590 attributes in that response is in the "utf-8" format?
2592 Example: Consider a case where a client sends a Print-Job request
2593 with "utf-8" as the value of "attributes-charset" and with the "job-
2594 name" attribute supplied. Later another client submits a Get-Job-
2595 Attribute or Get-Jobs request. This second request contains the
2596 "attributes-charset" with value "us-ascii" and "requested-attributes"
2597 attribute with exactly one value "job-name".
2599 According to the RFC2566 document (section 3.1.4.2), the value of the
2600 "attributes-charset" for the response of the second request must be
2601 "us-ascii" since that is the charset specified in the request. The
2602 "job-name" value, however, is in "utf-8" format. Should the request
2603 be rejected even though both "utf-8" and "us-ascii" charsets are
2604 supported by the server? or should the "job-name" value be converted
2605 to "us-ascii" and return "successful-ok-conflicting-attributes"
2606 (0x0002) as the status code?
2608 Answer: An IPP object that supports both utf-8 (REQUIRED) and us-
2609 ascii, the second paragraph of section 3.1.4.2 applies so that the
2610 IPP object MUST accept the request, perform code set conversion
2611 between these two charsets with "the highest fidelity possible" and
2612 return 'successful-ok', rather than a warning 'successful-ok-
2613 conflicting-attributes, or an error. The printer will do the best it
2614 can to convert between each of the character sets that it supports--
2615 even if that means providing a string of question marks because none
2616 of the characters are representable in US ASCII. If it can't perform
2617 such conversion, it MUST NOT advertise us-ascii as a value of its
2618 "attributes-charset-supported" and MUST reject any request that
2619 requests 'us-ascii'.
2621 One IPP object implementation strategy is to convert all request text
2622 and name values to a Unicode internal representation. This is 16-bit
2623 and virtually universal. Then convert to the specified operation
2624 attributes-charset on output.
2626 Also it would be smarter for a client to ask for 'utf-8', rather than
2627 'us-ascii' and throw away characters that it doesn't understand,
2628 rather than depending on the code conversion of the IPP object.
2634 Hastings & Manros Informational [Page 47]
2636 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2639 2.6.2 What charset to return when an unsupported charset is requested?
2641 Section 3.1.4.1 Request Operation attributes was clarified in
2642 November 1998 as follows:
2644 All clients and IPP objects MUST support the 'utf-8' charset
2645 [RFC2044] and MAY support additional charsets provided that they
2646 are registered with IANA [IANA-CS]. If the Printer object does
2647 not support the client supplied charset value, the Printer object
2648 MUST reject the request, set the "attributes-charset" to 'utf-8'
2649 in the response, and return the 'client-error-charset-not-
2650 supported' status code and any 'text' or 'name' attributes using
2651 the 'utf-8' charset.
2653 Since the client and IPP object MUST support UTF-8, returning any
2654 text or name attributes in UTF-8 when the client requests a charset
2655 that is not supported should allow the client to display the text or
2658 Since such an error is a client error, rather than a user error, the
2659 client should check the status code first so that it can avoid
2660 displaying any other returned 'text' and 'name' attributes that are
2661 not in the charset requested.
2663 Furthermore, [RFC2566] section 14.1.4.14 client-error-charset-not-
2664 supported (0x040D) was clarified in November 1998 as follows:
2666 For any operation, if the IPP Printer does not support the charset
2667 supplied by the client in the "attributes-charset" operation
2668 attribute, the Printer MUST reject the operation and return this
2669 status and any 'text' or 'name' attributes using the 'utf-8'
2670 charset (see Section 3.1.4.1).
2672 2.6.3 Natural Language Override (NLO)
2674 The 'text' and 'name' attributes each have two forms. One has an
2675 implicit natural language, and the other has an explicit natural
2676 language. The 'textWithoutLanguage' and 'textWithoutLanguage' are
2677 the two 'text' forms. The 'nameWithoutLanguage" and '
2678 nameWithLanguage are the two 'name' forms. If a receiver (IPP object
2679 or IPP client) supports an attribute with attribute syntax 'text', it
2680 MUST support both forms in a request and a response. A sender (IPP
2681 client or IPP object) MAY send either form for any such attribute.
2682 When a sender sends a WithoutLanguage form, the implicit natural
2683 language is specified in the "attributes-natural-language" operation
2684 attribute which all senders MUST include in every request and
2690 Hastings & Manros Informational [Page 48]
2692 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2695 When a sender sends a WithLanguage form, it MAY be different from the
2696 implicit natural language supplied by the sender or it MAY be the
2697 same. The receiver MUST treat either form equivalently.
2699 There is an implementation decision for senders, whether to always
2700 send the WithLanguage forms or use the WithoutLanguage form when the
2701 attribute's natural language is the same as the request or response.
2702 The former approach makes the sender implementation simpler. The
2703 latter approach is more efficient on the wire and allows inter-
2704 working with non-conforming receivers that fail to support the
2705 WithLanguage forms. As each approach have advantages, the choice is
2706 completely up to the implementer of the sender.
2708 Furthermore, when a client receives a 'text' or 'name' job attribute
2709 that it had previously supplied, that client MUST NOT expect to see
2710 the attribute in the same form, i.e., in the same WithoutLanguage or
2711 WithLanguage form as the client supplied when it created the job.
2712 The IPP object is free to transform the attribute from the
2713 WithLanguage form to the WithoutLanguage form and vice versa, as long
2714 as the natural language is preserved. However, in order to meet this
2715 latter requirement, it is usually simpler for the IPP object
2716 implementation to store the natural language explicitly with the
2717 attribute value, i.e., to store using an internal representation that
2718 resembles the WithLanguage form.
2720 The IPP Printer MUST copy the natural language of a job, i.e., the
2721 value of the "attributes-natural-language" operation attribute
2722 supplied by the client in the create operation, to the Job object as
2723 a Job Description attribute, so that a client is able to query it.
2724 In returning a Get-Job-Attributes response, the IPP object MAY return
2725 one of three natural language values in the response's "attributes-
2726 natural-language" operation attribute: (1) that requested by the
2727 requester, (2) the natural language of the job, or (3) the configured
2728 natural language of the IPP Printer, if the requested language is not
2729 supported by the IPP Printer.
2731 This "attributes-natural-language" Job Description attribute is
2732 useful for an IPP object implementation that prints start sheets in
2733 the language of the user who submitted the job. This same Job
2734 Description attribute is useful to a multi-lingual operator who has
2735 to communicate with different job submitters in different natural
2736 languages. This same Job Description attribute is expected to be
2737 used in the future to generate notification messages in the natural
2738 language of the job submitter.
2740 Early drafts of [RFC2566] contained a job-level natural language
2741 override (NLO) for the Get-Jobs response. A job-level (NLO) is an
2742 (unrequested) Job Attribute which then specified the implicit natural
2746 Hastings & Manros Informational [Page 49]
2748 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2751 language for any other WithoutLanguage job attributes returned in the
2752 response for that job. Interoperability testing of early
2753 implementations showed that no one was implementing the job-level NLO
2754 in Get-Job responses. So the job-level NLO was eliminated from the
2755 Get- Jobs response. This simplification makes all requests and
2756 responses consistent in that the implicit natural language for any
2757 WithoutLanguage 'text' or 'name' form is always supplied in the
2758 request's or response's "attributes-natural-language" operation
2761 2.7 The "queued-job-count" Printer Description attribute
2763 2.7.1 Why is "queued-job-count" RECOMMENDED?
2765 The reason that "queued-job-count" is RECOMMENDED, is that some
2766 clients look at that attribute alone when summarizing the status of a
2767 list of printers, instead of doing a Get-Jobs to determine the number
2768 of jobs in the queue. Implementations that fail to support the
2769 "queued-job-count" will cause that client to display 0 jobs when
2770 there are actually queued jobs.
2772 We would have made it a REQUIRED Printer attribute, but some
2773 implementations had already been completed before the issue was
2774 raised, so making it a SHOULD was a compromise.
2776 2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
2778 The "queued-job-count" is not a good measure of how busy the printer
2779 is when there are held jobs. A future registration could be to add a
2780 "held-job-count" (or an "active-job-count") Printer Description
2781 attribute if experience shows that such an attribute (combination) is
2782 needed to quickly indicate how busy a printer really is.
2784 2.8 Sending empty attribute groups
2786 The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender
2787 not send an empty attribute group in a request or a response.
2788 However, they REQUIRE a receiver to accept an empty attribute group
2789 as equivalent to the omission of that group. So a client SHOULD omit
2790 the Job Template Attributes group entirely in a create operation that
2791 is not supplying any Job Template attributes. Similarly, an IPP
2792 object SHOULD omit an empty Unsupported Attributes group if there are
2793 no unsupported attributes to be returned in a response.
2802 Hastings & Manros Informational [Page 50]
2804 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2807 The [RFC2565] specification REQUIRES a receiver to be able to receive
2808 either an empty attribute group or an omitted attribute group and
2809 treat them equivalently. The term "receiver" means an IPP object for
2810 a request and a client for a response. The term "sender' means a
2811 client for a request and an IPP object for a response.
2813 There is an exception to the rule for Get-Jobs when there are no
2814 attributes to be returned. [RFC2565] contains the following
2817 The syntax allows an xxx-attributes-tag to be present when the
2818 xxx-attribute-sequence that follows is empty. The syntax is
2819 defined this way to allow for the response of Get-Jobs where no
2820 attributes are returned for some job-objects. Although it is
2821 RECOMMENDED that the sender not send an xxx-attributes-tag if
2822 there are no attributes (except in the Get-Jobs response just
2823 mentioned), the receiver MUST be able to decode such syntax.
2825 2.9 Returning unsupported attributes in Get-Xxxx responses
2827 In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes
2828 responses, the client cannot depend on getting unsupported attributes
2829 returned in the Unsupported Attributes group that the client
2830 requested, but are not supported by the IPP object. However, such
2831 unsupported requested attributes will not be returned in the Job
2832 Attributes or Printer Attributes group (since they are unsupported).
2833 Furthermore, the IPP object is REQUIRED to return the 'successful-
2834 ok-ignored-or-substituted-attributes' status code, so that the client
2835 knows that not all that was requested has been returned.
2837 2.10 Returning job-state in Print-Job response
2839 An IPP client submits a small job via Print-Job. By the time the IPP
2840 printer/print server is putting together a response to the operation,
2841 the job has finished printing and been removed as an object from the
2842 print system. What should the job-state be in the response?
2844 The Model suggests that the Printer return a response before it even
2845 accepts the document content. The Job Object Attributes are returned
2846 only if the IPP object returns one of the success status codes. Then
2847 the job-state would always be "pending" or "pending-held".
2849 This issue comes up for the implementation of an IPP Printer object
2850 as a server that forwards jobs to devices that do not provide job
2851 status back to the server. If the server is reasonably certain that
2852 the job completed successfully, then it should return the job-state
2853 as 'completed'. Also the server can keep the job in its "job
2854 history" long after the job is no longer in the device. Then a user
2858 Hastings & Manros Informational [Page 51]
2860 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2863 could query the server and see that the job was in the 'completed'
2864 state and completed as specified by the job's "time-at-completed"
2865 time which would be the same as the server submitted the job to the
2868 An alternative is for the server to respond to the client before or
2869 while sending the job to the device, instead of waiting until the
2870 server has finished sending the job to the device. In this case, the
2871 server can return the job's state as 'pending' with the 'job-
2872 outgoing' value in the job's "job-state-reasons" attribute.
2874 If the server doesn't know for sure whether the job completed
2875 successfully (or at all), it could return the (out-of-band) 'unknown'
2878 On the other hand, if the server is able to query the device and/or
2879 setup some sort of event notification that the device initiates when
2880 the job makes state transitions, then the server can return the
2881 current job state in the Print-Job response and in subsequent queries
2882 because the server knows what the job state is in the device (or can
2885 All of these alternatives depend on implementation of the server and
2888 2.11 Flow controlling the data portion of a Print-Job request
2890 A paused printer (or one that is stopped due to paper out or jam or
2891 spool space full or buffer space full, may flow control the data of a
2892 Print-Job operation (at the TCP/IP layer), so that the client is not
2893 able to send all the document data. Consequently, the Printer will
2894 not return a response until the condition is changed.
2896 The Printer should not return a Print-Job response with an error code
2897 in any of these conditions, since either the printer will be resumed
2898 and/or the condition will be freed either by human intervention or as
2901 In writing test scripts to test IPP Printers, the script must also be
2902 written not to expect a response, if the printer has been paused,
2903 until the printer is resumed, in order to work with all possible
2906 2.12 Multi-valued attributes
2908 What is the attribute syntax for a multi-valued attribute? Since
2909 some attributes support values in more than one data type, such as
2910 "media", "job-hold-until", and "job-sheets", IPP semantics associate
2914 Hastings & Manros Informational [Page 52]
2916 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2919 the attribute syntax with each value, not with the attribute as a
2920 whole. The protocol associates the attribute syntax tag with each
2921 value. Don't be fooled, just because the attribute syntax tag comes
2922 before the attribute keyword. All attribute values after the first
2923 have a zero length attribute keyword as the indication of a
2924 subsequent value of the same attribute.
2926 2.13 Querying jobs with IPP that were submitted using other job
2927 submission protocols
2929 The following clarification was added to [RFC2566] section 8.5:
2931 8.5 Queries on jobs submitted using non-IPP protocols
2933 If the device that an IPP Printer is representing is able to
2934 accept jobs using other job submission protocols in addition to
2935 IPP, it is RECOMMEND that such an implementation at least allow
2936 such "foreign" jobs to be queried using Get-Jobs returning "job-
2937 id" and "job-uri" as 'unknown'. Such an implementation NEED NOT
2938 support all of the same IPP job attributes as for IPP jobs. The
2939 IPP object returns the 'unknown' out-of-band value for any
2940 requested attribute of a foreign job that is supported for IPP
2941 jobs, but not for foreign jobs.
2943 It is further RECOMMENDED, that the IPP Printer generate "job-id"
2944 and "job-uri" values for such "foreign jobs", if possible, so that
2945 they may be targets of other IPP operations, such as Get-Job-
2946 Attributes and Cancel-Job. Such an implementation also needs to
2947 deal with the problem of authentication of such foreign jobs. One
2948 approach would be to treat all such foreign jobs as belonging to
2949 users other than the user of the IPP client. Another approach
2950 would be for the foreign job to belong to 'anonymous'. Only if
2951 the IPP client has been authenticated as an operator or
2952 administrator of the IPP Printer object, could the foreign jobs be
2953 queried by an IPP request. Alternatively, if the security policy
2954 is to allow users to query other users' jobs, then the foreign
2955 jobs would also be visible to an end-user IPP client using Get-
2956 Jobs and Get-Job-Attributes.
2958 Thus IPP MAY be implemented as a "universal" protocol that provides
2959 access to jobs submitted with any job submission protocol. As IPP
2960 becomes widely implemented, providing a more universal access makes
2970 Hastings & Manros Informational [Page 53]
2972 RFC 2639 IPP/1.0: Implementer's Guide July 1999
2975 2.14 The 'none' value for empty sets
2977 [RFC2566] states that the 'none' value should be used as the value of
2978 a 1SetOf when the set is empty. In most cases, sets that are
2979 potentially empty contain keywords so the keyword 'none' is used, but
2980 for the 3 finishings attributes, the values are enums and thus the
2981 empty set is represented by the enum 3. Currently there are no other
2982 attributes with 1SetOf values which can be empty and can contain
2983 values that are not keywords. This exception requires special code
2984 and is a potential place for bugs. It would have been better if we
2985 had chosen an out-of-band value, either "no-value" or some new value,
2986 such as 'none'. Since we didn't, implementations have to deal with
2987 the different representations of 'none', depending on the attribute
2990 2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
2992 In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute '
2993 my-jobs' is present and set to TRUE, MUST the 'requesting-user-name'
2994 attribute be there to, and if it's not present what should the IPP
2997 [RFC2566] Section 8.3 describes the various cases of "requesting-
2998 user-name" being present or not for any operation. If the client
2999 does not supply a value for "requesting-user-name", the printer MUST
3000 assume that the client is supplying some anonymous name, such as
3003 2.16 The "multiple-document-handling" Job Template attribute and support
3004 of multiple document jobs
3006 ISSUE: IPP/1.0 is silent on which of the four effects an
3007 implementation would perform if it supports Create-Job, but does not
3008 support "multiple-document-handling".
3010 A fix to IPP/1.0 would be to require implementing all four values of
3011 "multiple-document-handling" if Create-Job is supported at all. Or
3012 at least 'single-document-new-sheet' and 'separate-documents-
3013 uncollated-copies'. In any case, an implementation that supports
3014 Create-Job SHOULD also support "multiple-document-handling". Support
3015 for all four values is RECOMMENDED, but at least the 'single-
3016 document-new-sheet' and 'separate-documents-uncollated-copies'
3017 values, along with the "multiple-document-handling-default"
3018 indicating the default behavior and "multiple-document-handling-
3019 supported" values. If an implementation spools the data, it should
3020 also support the 'separate-documents-collated-copies' value as well.
3026 Hastings & Manros Informational [Page 54]
3028 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3031 3 Encoding and Transport
3033 This section discusses various aspects of IPP/1.0 Encoding and
3034 Transport [RFC2565].
3036 A server is not required to send a response until after it has
3037 received the client.s entire request. Hence, a client must not
3038 expect a response until after it has sent the entire request.
3039 However, we recommend that the server return a response as soon as
3040 possible if an error is detected while the client is still sending
3041 the data, rather than waiting until all of the data is received.
3042 Therefore, we also recommend that a client listen for an error
3043 response that an IPP server MAY send before it receives all the data.
3044 In this case a client, if chunking the data, can send a premature
3045 zero-length chunk to end the request before sending all the data (and
3046 so the client can keep the connection open for other requests, rather
3047 than closing it). If the request is blocked for some reason, a client
3048 MAY determine the reason by opening another connection to query the
3049 server using Get-Printer-Attributes.
3051 In the following sections, there are a tables of all HTTP headers
3052 which describe their use in an IPP client or server. The following
3053 is an explanation of each column in these tables.
3055 - the .header. column contains the name of a header.
3056 - the .request/client. column indicates whether a client sends the
3058 - the .request/ server. column indicates whether a server supports
3059 the header when received.
3060 - the .response/ server. column indicates whether a server sends
3062 - the .response /client. column indicates whether a client
3063 supports the header when received.
3064 - the .values and conditions. column specifies the allowed header
3065 values and the conditions for the header to be present in a
3068 The table for .request headers. does not have columns for responses,
3069 and the table for .response headers. does not have columns for
3072 The following is an explanation of the values in the .request/client.
3073 and .response/ server. columns.
3075 - must: the client or server MUST send the header,
3076 - must-if: the client or server MUST send the header when the
3077 condition described in the .values and conditions. column is
3082 Hastings & Manros Informational [Page 55]
3084 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3087 - may: the client or server MAY send the header
3088 - not: the client or server SHOULD NOT send the header. It is not
3089 relevant to an IPP implementation.
3091 The following is an explanation of the values in the
3092 .response/client. and .request/ server. columns.
3094 - must: the client or server MUST support the header,
3095 - may: the client or server MAY support the header
3096 - not: the client or server SHOULD NOT support the header. It is
3097 not relevant to an IPP implementation.
3102 The following is a table for the general headers.
3105 General- Request Response Values and Conditions
3108 Client Server Server Client
3110 Cache- must not must not .no-cache. only
3113 Connection must-if must must- must .close. only. Both
3114 if client and server
3117 duration of a sequence
3119 client and server MUST
3121 for the last operation
3124 Date may may must may per RFC 1123 [RFC1123]
3128 Pragma must not must not .no-cache. only
3130 Transfer- must-if must must- must .chunked. only .
3131 Encoding if Header MUST be present
3132 if Content-Length is
3138 Hastings & Manros Informational [Page 56]
3140 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3143 Upgrade not not not not
3150 The following is a table for the request headers.
3153 Request-Header Client Server Request Values and Conditions
3155 Accept may must .application/ipp. only. This
3156 value is the default if the
3158 Request-Header Client Server Request Values and Conditions
3162 Accept-Charset not not Charset information is within
3163 the application/ipp entity
3165 Accept-Encoding may must empty and per RFC 2068 [RFC2068]
3166 and IANA registry for content-
3169 Accept-Language not not language information is within
3170 the application/ipp entity
3172 Authorization must-if must per RFC 2068. A client MUST send
3173 this header when it receives a
3174 401 .Unauthorized. response and
3175 does not receive a .Proxy-
3176 Authenticate. header.
3178 From not not per RFC 2068. Because RFC
3179 recommends sending this header
3180 only with the user.s approval, it
3183 Host must must per RFC 2068
3187 If-Modified- not not
3190 If-None-Match not not
3194 Hastings & Manros Informational [Page 57]
3196 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3201 If-Unmodified- not not
3204 Max-Forwards not not
3206 Proxy- must-if not per RFC 2068. A client MUST send
3207 Authorization this header when it receives a
3208 401 .Unauthorized. response and a
3209 .Proxy-Authenticate. header.
3218 3.3 Response Headers
3221 The following is a table for the request headers.
3224 Response- Server Client Response Values and Conditions
3227 Accept-Ranges not not
3231 Location must-if may per RFC 2068. When URI needs
3234 Proxy- not must per RFC 2068
3237 Public may may per RFC 2068
3239 Retry-After may may per RFC 2068
3245 Warning may may per RFC 2068
3250 Hastings & Manros Informational [Page 58]
3252 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3255 WWW- must-if must per RFC 2068. When a server needs to
3256 Authenticate authenticate a client.
3261 The following is a table for the entity headers.
3264 Entity-Header Request Response Values and Conditions
3266 Client Server Server Client
3268 Allow not not not not
3270 Content-Base not not not not
3272 Content- may must must must per RFC 2068 and IANA
3273 Encoding registry for content
3276 Content- not not not not Application/ipp
3277 Language handles language
3279 Content- must-if must must-if must the length of the
3280 Length message-body per RFC
3281 2068. Header MUST be
3282 present if Transfer-
3284 Entity-Header Request Response Values and Conditions
3286 Client Server Server Client
3290 Content- not not not not
3293 Content-MD5 may may may may per RFC 2068
3295 Content-Range not not not not
3297 Content-Type must must must must .application/ipp.
3300 ETag not not not not
3302 Expires not not not not
3306 Hastings & Manros Informational [Page 59]
3308 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3311 Last-Modified not not not not
3314 3.5 Optional support for HTTP/1.0
3316 IPP implementations consist of an HTTP layer and an IPP layer. In
3317 the following discussion, the term "client" refers to the HTTP client
3318 layer and the term "server" refers to the HTTP server layer. The
3319 Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST
3320 be supported by all clients and all servers. However, a client
3321 and/or a server implementation may choose to also support HTTP 1.0.
3323 - This option means that a server may choose to communicate with a
3324 (non-conforming) client that only supports HTTP 1.0. In such cases
3325 the server should not use any HTTP 1.1 specific parameters or
3326 features and should respond using HTTP version number 1.0.
3328 - This option also means that a client may choose to communicate with
3329 a (non-conforming) server that only supports HTTP 1.0. In such
3330 cases, if the server responds with an HTTP .unsupported version
3331 number. to an HTTP 1.1 request, the client should retry using HTTP
3334 3.6 HTTP/1.1 Chunking
3336 3.6.1 Disabling IPP Server Response Chunking
3338 Clients MUST anticipate that the HTTP/1.1 server may chunk responses
3339 and MUST accept them in responses. However, a (non-conforming) HTTP
3340 client that is unable to accept chunked responses may attempt to
3341 request an HTTP 1.1 server not to use chunking in its response to an
3342 operation by using the following HTTP header:
3346 This mechanism should not be used by a server to disable a client
3347 from chunking a request, since chunking of document data is an
3348 important feature for clients to send long documents.
3350 3.6.2 Warning About the Support of Chunked Requests
3352 This section describes some problems with the use of chunked requests
3353 and HTTP/1.1 servers.
3355 The HTTP/1.1 standard [HTTP] requires that conforming servers support
3356 chunked requests for any method. However, in spite of this
3357 requirement, some HTTP/1.1 implementations support chunked responses
3358 in the GET method, but do not support chunked POST method requests.
3362 Hastings & Manros Informational [Page 60]
3364 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3367 Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or
3368 servlets [Servlet] require that the client supply a Content-Length.
3369 These implementations might reject a chunked POST method and return a
3370 411 status code (Length Required), might attempt to buffer the
3371 request and run out of room returning a 413 status code (Request
3372 Entity Too Large), or might successfully accept the chunked request.
3374 Because of this lack of conformance of HTTP servers to the HTTP/1.1
3375 standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP
3376 Printer object implementation support chunked requests and that
3377 conforming clients accept chunked responses. Therefore, IPP object
3378 implementers are warned to seek HTTP server implementations that
3379 support chunked POST requests in order to conform to the IPP standard
3380 and/or use implementation techniques that support chunked POST
3385 [CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface
3386 Version 1.1 (CGI/1.1)", Work in Progress.
3388 [HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter,
3389 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
3390 Protocol -- HTTP/1.1", RFC 2616, June 1999.
3392 [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
3393 "Mapping between LPD and IPP Protocols", RFC 2569, April
3396 [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P.
3397 Powell, "Internet Printing Protocol/1.0: Model and
3398 Semantics", RFC 2566, April 1999.
3400 [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
3401 Printing Protocol/1.0: Encoding and Transport", RFC 2565,
3404 [RFC2568] Zilles, S., "Rationale for the Structure and Model and
3405 Protocol for the Internet Printing Protocol", RFC 2568,
3408 [RFC2567] Wright, D., "Design Goals for an Internet Printing
3409 Protocol", RFC 2567, April 1999.
3411 [RFC1123] Braden, S., "Requirements for Internet Hosts - Application
3412 and Support", STD 3, RFC 1123, October 1989.
3418 Hastings & Manros Informational [Page 61]
3420 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3423 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3424 3", BCP 9, RFC 2026, October 1996.
3426 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
3427 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
3430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
3431 Requirement Levels", BCP 14, RFC 2119, March 1997.
3433 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
3434 Resource Identifiers (URI): Generic Syntax", RFC 2396,
3437 [Servlet] Servlet Specification Version 2.1
3438 (http://java.sun.com/products/servlet/2.1/index.html).
3440 [SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02),
3443 4.1 Authors' Addresses
3448 El Segundo, CA 90245
3450 EMail: hastings@cp10.es.xerox.com
3456 El Segundo, CA 90245
3458 EMail: manros@cp10.es.xerox.com
3460 5 Security Considerations
3462 Security issues are discussed in sections 2.2, 2.3.1, and 8.5.
3466 The IETF takes no position regarding the validity or scope of any
3467 intellectual property or other rights that might be claimed to
3468 pertain to the implementation or use of the technology described in
3469 this document or the extent to which any license under such rights
3470 might or might not be available; neither does it represent that it
3474 Hastings & Manros Informational [Page 62]
3476 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3479 has made any effort to identify any such rights. Information on the
3480 IETF's procedures with respect to rights in standards-track and
3481 standards-related documentation can be found in BCP-11 [BCP-11].
3482 Copies of claims of rights made available for publication and any
3483 assurances of licenses to be made available, or the result of an
3484 attempt made to obtain a general license or permission for the use of
3485 such proprietary rights by implementers or users of this
3486 specification can be obtained from the IETF Secretariat.
3488 The IETF invites any interested party to bring to its attention any
3489 copyrights, patents or patent applications, or other proprietary
3490 rights which may cover technology that may be required to practice
3491 this standard. Please address the information to the IETF Executive
3530 Hastings & Manros Informational [Page 63]
3532 RFC 2639 IPP/1.0: Implementer's Guide July 1999
3535 Full Copyright Statement
3537 Copyright (C) The Internet Society (1999). All Rights Reserved.
3539 This document and translations of it may be copied and furnished to
3540 others, and derivative works that comment on or otherwise explain it
3541 or assist in its implementation may be prepared, copied, published
3542 and distributed, in whole or in part, without restriction of any
3543 kind, provided that the above copyright notice and this paragraph are
3544 included on all such copies and derivative works. However, this
3545 document itself may not be modified in any way, such as by removing
3546 the copyright notice or references to the Internet Society or other
3547 Internet organizations, except as needed for the purpose of
3548 developing Internet standards in which case the procedures for
3549 copyrights defined in the Internet Standards process must be
3550 followed, or as required to translate it into languages other than
3553 The limited permissions granted above are perpetual and will not be
3554 revoked by the Internet Society or its successors or assigns.
3556 This document and the information contained herein is provided on an
3557 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
3558 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
3559 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
3560 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
3561 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3565 Funding for the RFC Editor function is currently provided by the
3586 Hastings & Manros Informational [Page 64]