RFC 3196
Internet Printing Protocol/1.1: Implementor's Guide
4.5 Empty Jobs
The IPP object model does not prohibit a job that contains no documents. Such a job may be created in a number of ways including a 'create-job' followed by an 'add-document' that contains no data and has the 'last-document' flag set. An empty job is processed just as any other job. The operation that "closes" an empty job is not rejected because the job is empty. If no other conditions exist, other than the job is empty, the response to the operation will indicate success. After the job is scheduled and processed, the job state SHALL be 'completed'. There will be some variation in the value(s) of the "job-state- reasons" attribute. It is required that if no conditions, other than the job being empty, exist the "job-state-reasons" SHALL include the 'completed-successfully'. If other conditions existed, the 'completed-with-warnings' or 'completed-with-errors' values may be used.5 Directory Considerations
5.1 General Directory Schema Considerations
The [RFC2911] document lists RECOMMENDED and OPTIONAL Printer object attributes for directory schemas. See [RFC2911] APPENDIX E: Generic Directory Schema. The SLP printer template is defined in the "Definition of the Printer Abstract Service Type v2.0" document [svrloc-printer]. The LDAP printer template is defined in the "Internet Printing Protocol (IPP): LDAP Schema for Printer Services" document [ldap-printer]. Both documents systematically add "printer-" to any attribute that doesn't already start with "printer-" in order to keep the printer directory attributes distinct from other directory attributes. Also, instead of using "printer-uri-supported", "uri-authentication-supported", and "uri-security-supported", they use a "printer-xri-supported" attribute with special syntax to contain all of the same information in a single attribute.5.2 IPP Printer with a DNS name
If the IPP printer has a DNS name should there be at least two values for the printer-uri-supported attribute. One URL with the fully qualified DNS name the other with the IP address in the URL?
The printer may contain one or the other or both. It's up to the administrator to configure this attribute.6 Security Considerations
The security considerations given in [RFC2911] Section 8 "Security Considerations" all apply to this document. In addition, the following sub-sections describes security consideration that have arisen as a result of implementation testing.6.1 Querying jobs with IPP that were submitted using other job submission protocols (Issue 1.32)
The following clarification was added to [RFC2911] 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 were 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.
7 Encoding and Transport
This section discusses various aspects of IPP/1.1 Encoding and Transport [RFC2910]. 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. IPP, by design, uses TCP's built-in flow control mechanisms [RFC 793] to throttle clients when Printers are busy. Therefore, it is perfectly normal for an IPP client transmitting a Job to be blocked for a really long time. Accordingly, socket timeouts must be avoided. Some socket implementations have a timeout option, which specifies how long a write operation on a socket can be blocked before it times out and the blocking ends. A client should set this option for infinite timeout when transmitting Job submissions. Some IPP client applications might be able to perform other useful work while a Job transmission is blocked. For example, the client may have other jobs that it could transmit to other Printers simultaneously. A client may have a GUI, which must remain responsive to the user while the Job transmission is blocked. These clients should be designed to spawn a thread to handle the Job transmission at its own pace, leaving the main application free to do other work. Alternatively, single-threaded applications could use non-blocking I/O. Some Printer conditions, such as jam or lack of paper, could cause a client to be blocked indefinitely. Clients may open additional connections to the Printer to Get-Printer-Attributes, determine the state of the device, alert a user if the printer is stopped, and let a user decide whether to abort the job transmission or not. In the following sections, there are 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.
7.1 General Headers
The following is a table for the general headers. General- Request Response Values and Conditions Header Client Server Server Client Cache- not must not "no-cache" only Control must Connection must- must must- must "close" only. Both if 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 2616 [RFC2616] Pragma must not must not "no-cache" only Transfer- must- must must- must "chunked" only. Header Encoding if if MUST be present if Content-Length is absent. Upgrade not not not not Via not not not not
7.2 Request Headers
The following is a table for the request headers. Request- Client Server Request Values and Conditions Header Accept may must "application/ipp" only. This value is the default if the client omits it Accept- not not Charset information is within the Charset application/ipp entity Accept- may must empty and per RFC 2616 [RFC2616] Encoding and IANA registry for content- codings Accept- not not language information is within the Language application/ipp entity Authorization must- must per RFC 2616. A client MUST send if this header when it receives a 401 "Unauthorized" response and does not receive a "Proxy- Authenticate" header. From not not per RFC 2616. Because RFC recommends sending this header only with the user's approval, it is not very useful Host must must per RFC 2616 If-Match not not If-Modified- not not Since If-None-Match not not If-Range not not If- not not Unmodified- Since
Request- Client Server Request Values and Conditions Header Max-Forwards not not Proxy- must- not per RFC 2616. A client MUST send Authorizati if this header when it receives a on 401 "Unauthorized" response and a "Proxy-Authenticate" header. Range not not Referrer not not User-Agent not not
7.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- may per RFC 2616. When URI needs if redirection. Proxy- must per RFC 2616 Authenticat e not Public may may per RFC 2616 Retry-After may may per RFC 2616 Server not not Vary not not Warning may may per RFC 2616 WWW- must- must per RFC 2616. When a server needs Authenticate if to authenticate a client.
7.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 2616 and Encoding IANA registry for content codings. Content- not not not not Application/ipp Language handles language Content- must- must must- must the length of the Length if if message-body per RFC 2616. Header MUST be present if Transfer- Encoding is absent.. Content- not not not not Location Content-MD5 may may may may per RFC 2616 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 not
7.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 [RFC2910] 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.7.6 HTTP/1.1 Chunking
7.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.7.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 [RFC2616] 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 [RFC2910] 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.8 References
[CGI] CGI/1.1 (http://www.w3.org/CGI/). [IANA-CS] IANA Registry of Coded Character Sets: http://www.iana.org/assignments/character-sets [ldap-printer] Fleming, P., Jones, K., Lewis, H. and I. McDonald, "Internet Printing Protocol (IPP): LDAP Schema for Printer Services", Work in Progress. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October, 1989. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [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. [RFC2565] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[RFC2566] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. [RFC2567] Wright, D., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999. [RFC2568] Zilles, S., "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999. [RFC2569] Herriot, R., Hastings, T., Jacobs, N. and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999. [RFC2616] 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. [RFC2910] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2910, September, 2000. [RFC2911] DeBry, R., Hastings, T., Herriot, R., Isaacson, S. and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2911, September, 2000. [Servlet] Servlet Specification Version 2.1 (http://java.sun.com/products/servlet/2.1/ index.html). [svrloc-printer] St. Pierre, P., Isaacson, S., McDonald, I., "Definition of the Printer Abstract Service Type v2.0", http://www.isi.edu/in- notes/iana/assignments/svrloc- templates/printer.2.0.en (IANA Registered, May 27, 2000). [SSL] Netscape, The SSL Protocol, Version 3, (Text version 3.02), November 1996.
9. Authors' Addresses
Thomas N. Hastings Xerox Corporation 701 Aviation Blvd. El Segundo, CA 90245 EMail: hastings@cp10.es.xerox.com Carl-Uno Manros Independent Consultant 1601 N. Sepulveda Blvd. #505 Manhattan Beach, CA 90266 Email: carl@manros.com Carl Kugler Mail Stop 003G IBM Printing Systems Co 6300 Diagonal Hwy Boulder CO 80301 EMail: Kugler@us.ibm.com Henrik Holst i-data Printing Systems Vadstrupvej 35-43 2880 Bagsvaerd, Denmark EMail: hh@I-data.com Peter Zehler Xerox Corporation 800 Philips Road Webster, NY 14580 EMail: PZehler@crt.xerox.com
IPP Web Page: http://www.pwg.org/ipp/ IPP Mailing List: ipp@pwg.org To subscribe to the ipp mailing list, send the following email: 1) send it to majordomo@pwg.org 2) leave the subject line blank 3) put the following two lines in the message body: subscribe ipp end Implementers of this specification document are encouraged to join the IPP Mailing List in order to participate in any discussions of clarification issues and review of registration proposals for additional attributes and values. In order to reduce spam the mailing list rejects mail from non-subscribers, so you must subscribe to the mailing list in order to send a question or comment to the mailing list. Other Participants: Chuck Adams - Tektronix Shivaun Albright - HP Stefan Andersson - Axis Jeff Barnett - IBM Ron Bergman - Hitachi Koki Dennis Carney - IBM Imaging Systems Keith Carter - IBM Angelo Caruso - Xerox Rajesh Chawla - TR Computing Nancy Chen - Okidata Solutions Josh Cohen - Microsoft Jeff Copeland - QMS Andy Davidson - Tektronix Roger deBry - IBM Maulik Desai - Auco Mabry Dozier - QMS Lee Farrell - Canon Information Satoshi Fujitami - Ricoh Systems Steve Gebert - IBM Sue Gleeson - Digital Charles Gordon - Osicom Brian Grimshaw - Apple Jerry Hadsell - IBM Richard Hart - Digital
Tom Hastings - Xerox Henrik Holst - I-data
Stephen Holmstead Zhi-Hong Huang - Zenographics
Scott Isaacson - Novell Babek Jahromi - Microsoft
Swen Johnson - Xerox David Kellerman - Northlake
Software
Robert Kline - TrueSpectra Charles Kong - Panasonic
Carl Kugler - IBM Dave Kuntz - Hewlett-Packard
Takami Kurono - Brother Rick Landau - Digital
Scott Lawrence - Agranot Systems Greg LeClair - Epson
Dwight Lewis - Lexmark Harry Lewis - IBM
Tony Liao - Vivid Image Roy Lomicka - Digital
Pete Loya - HP Ray Lutz - Cognisys
Mike MacKay - Novell, Inc. David Manchala - Xerox
Carl-Uno Manros - Xerox Jay Martin - Underscore
Stan McConnell - Xerox Larry Masinter - Xerox
Sandra Matts - Hewlett Packard Peter Michalek - Shinesoft
Ira McDonald - High North Inc. Mike Moldovan - G3 Nova
Tetsuya Morita - Ricoh Yuichi Niwa - Ricoh
Pat Nogay - IBM Ron Norton - Printronics
Hugo Parra, Novell Bob Pentecost - Hewlett-Packard
Patrick Powell - Astart Jeff Rackowitz - Intermec
Technologies
Eric Random - Peerless Rob Rhoads - Intel
Xavier Riley - Xerox Gary Roberts - Ricoh
David Roach - Unisys Stuart Rowley - Kyocera
Yuji Sasaki - Japan Computer Richard Schneider - Epson
Industry
Kris Schoff - HP Katsuaki Sekiguchi - Canon
Bob Setterbo - Adobe Gail Songer - Peerless
Hideki Tanaka - Canon Devon Taylor - Novell, Inc.
Mike Timperman - Lexmark Atsushi Uchino - Epson
Shigeru Ueda - Canon Bob Von Andel - Allegro Software
William Wagner - NetSilicon/DPI Jim Walker - DAZEL
Chris Wellens - Interworking Labs Trevor Wells - Hewlett Packard
Craig Whittle - Sharp Labs Rob Whittle - Novell, Inc.
Jasper Wong - Xionics Don Wright - Lexmark
Michael Wu - Heidelberg Digital Rick Yardumian - Xerox
Michael Yeung - Toshiba Lloyd Young - Lexmark
Atsushi Yuki - Kyocera Peter Zehler - Xerox
William Zhang- Canon Information Frank Zhao - Panasonic
Systems
Steve Zilles - Adobe Rob Zirnstein - Canon
Information Systems
10. Description of the Base IPP Documents
In addition to this document, the base set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the
Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator operations have been added to IPP/1.1 [RFC2911, RFC2910]. The "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specification documents, and gives background and rationale for the IETF IPP working group's major decisions. The "Internet Printing Protocol/1.1: Model and Semantics" document describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. The Job supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a new Internet MIME media type called "application/ipp". This document also defines the rules for transporting a message body over HTTP whose Content-Type is "application/ipp". This document defines the 'ipp' scheme for identifying IPP printers and jobs. The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon) implementations.
11 Full Copyright Statement
Copyright (C) The Internet Society (2001). 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.