RFC 2639
Internet Printing Protocol/1.0: Implementer's Guide
2.7 The "queued-job-count" Printer Description attribute
2.7.1 Why is "queued-job-count" RECOMMENDED?
The reason that "queued-job-count" is RECOMMENDED, is that some clients look at that attribute alone when summarizing the status of a list of printers, instead of doing a Get-Jobs to determine the number of jobs in the queue. Implementations that fail to support the "queued-job-count" will cause that client to display 0 jobs when there are actually queued jobs. We would have made it a REQUIRED Printer attribute, but some implementations had already been completed before the issue was raised, so making it a SHOULD was a compromise.2.7.2 Is "queued-job-count" a good measure of how busy a printer is?
The "queued-job-count" is not a good measure of how busy the printer is when there are held jobs. A future registration could be to add a "held-job-count" (or an "active-job-count") Printer Description attribute if experience shows that such an attribute (combination) is needed to quickly indicate how busy a printer really is.2.8 Sending empty attribute groups
The [RFC2566] and [RFC2565] specifications RECOMMEND that a sender not send an empty attribute group in a request or a response. However, they REQUIRE a receiver to accept an empty attribute group as equivalent to the omission of that group. So a client SHOULD omit the Job Template Attributes group entirely in a create operation that is not supplying any Job Template attributes. Similarly, an IPP object SHOULD omit an empty Unsupported Attributes group if there are no unsupported attributes to be returned in a response.
The [RFC2565] specification REQUIRES a receiver to be able to receive either an empty attribute group or an omitted attribute group and treat them equivalently. The term "receiver" means an IPP object for a request and a client for a response. The term "sender' means a client for a request and an IPP object for a response. There is an exception to the rule for Get-Jobs when there are no attributes to be returned. [RFC2565] contains the following paragraph: The syntax allows an xxx-attributes-tag to be present when the xxx-attribute-sequence that follows is empty. The syntax is defined this way to allow for the response of Get-Jobs where no attributes are returned for some job-objects. Although it is RECOMMENDED that the sender not send an xxx-attributes-tag if there are no attributes (except in the Get-Jobs response just mentioned), the receiver MUST be able to decode such syntax.2.9 Returning unsupported attributes in Get-Xxxx responses
In the Get-Printer-Attributes, Get-Jobs, or Get-Job-Attributes responses, the client cannot depend on getting unsupported attributes returned in the Unsupported Attributes group that the client requested, but are not supported by the IPP object. However, such unsupported requested attributes will not be returned in the Job Attributes or Printer Attributes group (since they are unsupported). Furthermore, the IPP object is REQUIRED to return the 'successful- ok-ignored-or-substituted-attributes' status code, so that the client knows that not all that was requested has been returned.2.10 Returning job-state in Print-Job response
An IPP client submits a small job via Print-Job. By the time the IPP printer/print server is putting together a response to the operation, the job has finished printing and been removed as an object from the print system. What should the job-state be in the response? The Model suggests that the Printer return a response before it even accepts the document content. The Job Object Attributes are returned only if the IPP object returns one of the success status codes. Then the job-state would always be "pending" or "pending-held". This issue comes up for the implementation of an IPP Printer object as a server that forwards jobs to devices that do not provide job status back to the server. If the server is reasonably certain that the job completed successfully, then it should return the job-state as 'completed'. Also the server can keep the job in its "job history" long after the job is no longer in the device. Then a user
could query the server and see that the job was in the 'completed' state and completed as specified by the job's "time-at-completed" time which would be the same as the server submitted the job to the device. An alternative is for the server to respond to the client before or while sending the job to the device, instead of waiting until the server has finished sending the job to the device. In this case, the server can return the job's state as 'pending' with the 'job- outgoing' value in the job's "job-state-reasons" attribute. If the server doesn't know for sure whether the job completed successfully (or at all), it could return the (out-of-band) 'unknown' value. On the other hand, if the server is able to query the device and/or setup some sort of event notification that the device initiates when the job makes state transitions, then the server can return the current job state in the Print-Job response and in subsequent queries because the server knows what the job state is in the device (or can query the device). All of these alternatives depend on implementation of the server and the device.2.11 Flow controlling the data portion of a Print-Job request
A paused printer (or one that is stopped due to paper out or jam or spool space full or buffer space full, may flow control the data of a Print-Job operation (at the TCP/IP layer), so that the client is not able to send all the document data. Consequently, the Printer will not return a response until the condition is changed. The Printer should not return a Print-Job response with an error code in any of these conditions, since either the printer will be resumed and/or the condition will be freed either by human intervention or as jobs print. In writing test scripts to test IPP Printers, the script must also be written not to expect a response, if the printer has been paused, until the printer is resumed, in order to work with all possible implementations.2.12 Multi-valued attributes
What is the attribute syntax for a multi-valued attribute? Since some attributes support values in more than one data type, such as "media", "job-hold-until", and "job-sheets", IPP semantics associate
the attribute syntax with each value, not with the attribute as a whole. The protocol associates the attribute syntax tag with each value. Don't be fooled, just because the attribute syntax tag comes before the attribute keyword. All attribute values after the first have a zero length attribute keyword as the indication of a subsequent value of the same attribute.2.13 Querying jobs with IPP that were submitted using other job submission protocols
The following clarification was added to [RFC2566] section 8.5: 8.5 Queries on jobs submitted using non-IPP protocols If the device that an IPP Printer is representing is able to accept jobs using other job submission protocols in addition to IPP, it is RECOMMEND that such an implementation at least allow such "foreign" jobs to be queried using Get-Jobs returning "job- id" and "job-uri" as 'unknown'. Such an implementation NEED NOT support all of the same IPP job attributes as for IPP jobs. The IPP object returns the 'unknown' out-of-band value for any requested attribute of a foreign job that is supported for IPP jobs, but not for foreign jobs. It is further RECOMMENDED, that the IPP Printer generate "job-id" and "job-uri" values for such "foreign jobs", if possible, so that they may be targets of other IPP operations, such as Get-Job- Attributes and Cancel-Job. Such an implementation also needs to deal with the problem of authentication of such foreign jobs. One approach would be to treat all such foreign jobs as belonging to users other than the user of the IPP client. Another approach would be for the foreign job to belong to 'anonymous'. Only if the IPP client has been authenticated as an operator or administrator of the IPP Printer object, could the foreign jobs be queried by an IPP request. Alternatively, if the security policy is to allow users to query other users' jobs, then the foreign jobs would also be visible to an end-user IPP client using Get- Jobs and Get-Job-Attributes. Thus IPP MAY be implemented as a "universal" protocol that provides access to jobs submitted with any job submission protocol. As IPP becomes widely implemented, providing a more universal access makes sense.
2.14 The 'none' value for empty sets
[RFC2566] states that the 'none' value should be used as the value of a 1SetOf when the set is empty. In most cases, sets that are potentially empty contain keywords so the keyword 'none' is used, but for the 3 finishings attributes, the values are enums and thus the empty set is represented by the enum 3. Currently there are no other attributes with 1SetOf values which can be empty and can contain values that are not keywords. This exception requires special code and is a potential place for bugs. It would have been better if we had chosen an out-of-band value, either "no-value" or some new value, such as 'none'. Since we didn't, implementations have to deal with the different representations of 'none', depending on the attribute syntax.2.15 Get-Jobs, my-jobs='true', and 'requesting-user-name'?
In [RFC2566] section 3.2.6.1 'Get-Jobs Request', if the attribute ' my-jobs' is present and set to TRUE, MUST the 'requesting-user-name' attribute be there to, and if it's not present what should the IPP printer do? [RFC2566] Section 8.3 describes the various cases of "requesting- user-name" being present or not for any operation. If the client does not supply a value for "requesting-user-name", the printer MUST assume that the client is supplying some anonymous name, such as "anonymous".2.16 The "multiple-document-handling" Job Template attribute and support of multiple document jobs
ISSUE: IPP/1.0 is silent on which of the four effects an implementation would perform if it supports Create-Job, but does not support "multiple-document-handling". A fix to IPP/1.0 would be to require implementing all four values of "multiple-document-handling" if Create-Job is supported at all. Or at least 'single-document-new-sheet' and 'separate-documents- uncollated-copies'. In any case, an implementation that supports Create-Job SHOULD also support "multiple-document-handling". Support for all four values is RECOMMENDED, but at least the 'single- document-new-sheet' and 'separate-documents-uncollated-copies' values, along with the "multiple-document-handling-default" indicating the default behavior and "multiple-document-handling- supported" values. If an implementation spools the data, it should also support the 'separate-documents-collated-copies' value as well.
3 Encoding and Transport
This section discusses various aspects of IPP/1.0 Encoding and Transport [RFC2565]. A server is not required to send a response until after it has received the client.s entire request. Hence, a client must not expect a response until after it has sent the entire request. However, we recommend that the server return a response as soon as possible if an error is detected while the client is still sending the data, rather than waiting until all of the data is received. Therefore, we also recommend that a client listen for an error response that an IPP server MAY send before it receives all the data. In this case a client, if chunking the data, can send a premature zero-length chunk to end the request before sending all the data (and so the client can keep the connection open for other requests, rather than closing it). If the request is blocked for some reason, a client MAY determine the reason by opening another connection to query the server using Get-Printer-Attributes. In the following sections, there are a tables of all HTTP headers which describe their use in an IPP client or server. The following is an explanation of each column in these tables. - the .header. column contains the name of a header. - the .request/client. column indicates whether a client sends the header. - the .request/ server. column indicates whether a server supports the header when received. - the .response/ server. column indicates whether a server sends the header. - the .response /client. column indicates whether a client supports the header when received. - the .values and conditions. column specifies the allowed header values and the conditions for the header to be present in a request/response. The table for .request headers. does not have columns for responses, and the table for .response headers. does not have columns for requests. The following is an explanation of the values in the .request/client. and .response/ server. columns. - must: the client or server MUST send the header, - must-if: the client or server MUST send the header when the condition described in the .values and conditions. column is met,
- may: the client or server MAY send the header
- not: the client or server SHOULD NOT send the header. It is not
relevant to an IPP implementation.
The following is an explanation of the values in the
.response/client. and .request/ server. columns.
- must: the client or server MUST support the header,
- may: the client or server MAY support the header
- not: the client or server SHOULD NOT support the header. It is
not relevant to an IPP implementation.
3.1 General Headers
The following is a table for the general headers.
General- Request Response Values and Conditions
Header
Client Server Server Client
Cache- must not must not .no-cache. only
Control
Connection must-if must must- must .close. only. Both
if client and server
SHOULD keep a
connection for the
duration of a sequence
of operations. The
client and server MUST
include this header
for the last operation
in such a sequence.
Date may may must may per RFC 1123 [RFC1123]
from RFC 2068
[RFC2068]
Pragma must not must not .no-cache. only
Transfer- must-if must must- must .chunked. only .
Encoding if Header MUST be present
if Content-Length is
absent.
Upgrade not not not not Via not not not not3.2 Request Headers
The following is a table for the request headers. Request-Header Client Server Request Values and Conditions Accept may must .application/ipp. only. This value is the default if the Request-Header Client Server Request Values and Conditions client omits it Accept-Charset not not Charset information is within the application/ipp entity Accept-Encoding may must empty and per RFC 2068 [RFC2068] and IANA registry for content- codings Accept-Language not not language information is within the application/ipp entity Authorization must-if must per RFC 2068. A client MUST send this header when it receives a 401 .Unauthorized. response and does not receive a .Proxy- Authenticate. header. From not not per RFC 2068. Because RFC recommends sending this header only with the user.s approval, it is not very useful Host must must per RFC 2068 If-Match not not If-Modified- not not Since If-None-Match not not
If-Range not not If-Unmodified- not not Since Max-Forwards not not Proxy- must-if not per RFC 2068. A client MUST send Authorization this header when it receives a 401 .Unauthorized. response and a .Proxy-Authenticate. header. Range not not Referer not not User-Agent not not3.3 Response Headers
The following is a table for the request headers. Response- Server Client Response Values and Conditions Header Accept-Ranges not not Age not not Location must-if may per RFC 2068. When URI needs redirection. Proxy- not must per RFC 2068 Authenticate Public may may per RFC 2068 Retry-After may may per RFC 2068 Server not not Vary not not Warning may may per RFC 2068
WWW- must-if must per RFC 2068. When a server needs to Authenticate authenticate a client.3.4 Entity Headers
The following is a table for the entity headers. Entity-Header Request Response Values and Conditions Client Server Server Client Allow not not not not Content-Base not not not not Content- may must must must per RFC 2068 and IANA Encoding registry for content codings. Content- not not not not Application/ipp Language handles language Content- must-if must must-if must the length of the Length message-body per RFC 2068. Header MUST be present if Transfer- Entity-Header Request Response Values and Conditions Client Server Server Client Encoding is absent. Content- not not not not Location Content-MD5 may may may may per RFC 2068 Content-Range not not not not Content-Type must must must must .application/ipp. only ETag not not not not Expires not not not not
Last-Modified not not not not3.5 Optional support for HTTP/1.0
IPP implementations consist of an HTTP layer and an IPP layer. In the following discussion, the term "client" refers to the HTTP client layer and the term "server" refers to the HTTP server layer. The Encoding and Transport document [RFC2565] requires that HTTP 1.1 MUST be supported by all clients and all servers. However, a client and/or a server implementation may choose to also support HTTP 1.0. - This option means that a server may choose to communicate with a (non-conforming) client that only supports HTTP 1.0. In such cases the server should not use any HTTP 1.1 specific parameters or features and should respond using HTTP version number 1.0. - This option also means that a client may choose to communicate with a (non-conforming) server that only supports HTTP 1.0. In such cases, if the server responds with an HTTP .unsupported version number. to an HTTP 1.1 request, the client should retry using HTTP version number 1.0.3.6 HTTP/1.1 Chunking
3.6.1 Disabling IPP Server Response Chunking
Clients MUST anticipate that the HTTP/1.1 server may chunk responses and MUST accept them in responses. However, a (non-conforming) HTTP client that is unable to accept chunked responses may attempt to request an HTTP 1.1 server not to use chunking in its response to an operation by using the following HTTP header: TE: identity This mechanism should not be used by a server to disable a client from chunking a request, since chunking of document data is an important feature for clients to send long documents.3.6.2 Warning About the Support of Chunked Requests
This section describes some problems with the use of chunked requests and HTTP/1.1 servers. The HTTP/1.1 standard [HTTP] requires that conforming servers support chunked requests for any method. However, in spite of this requirement, some HTTP/1.1 implementations support chunked responses in the GET method, but do not support chunked POST method requests.
Some HTTP/1.1 implementations that support CGI scripts [CGI] and/or servlets [Servlet] require that the client supply a Content-Length. These implementations might reject a chunked POST method and return a 411 status code (Length Required), might attempt to buffer the request and run out of room returning a 413 status code (Request Entity Too Large), or might successfully accept the chunked request. Because of this lack of conformance of HTTP servers to the HTTP/1.1 standard, the IPP standard [RFC2565] REQUIRES that a conforming IPP Printer object implementation support chunked requests and that conforming clients accept chunked responses. Therefore, IPP object implementers are warned to seek HTTP server implementations that support chunked POST requests in order to conform to the IPP standard and/or use implementation techniques that support chunked POST requests.4 References
[CGI] Coar, K. and D. Robinson, "The WWW Common Gateway Interface Version 1.1 (CGI/1.1)", Work in Progress. [HTTP] Fielding, R., Gettys,J., Mogul, J., Frystyk,, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999. [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999. [RFC2565] Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. [RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999. [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999. [RFC1123] Braden, S., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [Servlet] Servlet Specification Version 2.1 (http://java.sun.com/products/servlet/2.1/index.html). [SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.4.1 Authors' Addresses
Thomas N. Hastings Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 EMail: hastings@cp10.es.xerox.com Carl-Uno Manros Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 EMail: manros@cp10.es.xerox.com5 Security Considerations
Security issues are discussed in sections 2.2, 2.3.1, and 8.5.6 Notices
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11 [BCP-11]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.