Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3196

Internet Printing Protocol/1.1: Implementor's Guide

Pages: 96
Informational
Errata
Obsoletes:  2639
Part 5 of 5 – Pages 79 to 96
First   Prev   None

Top   ToC   RFC3196 - Page 79   prevText

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?
Top   ToC   RFC3196 - Page 80
   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.
Top   ToC   RFC3196 - Page 81

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.
Top   ToC   RFC3196 - Page 82
     - 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.
Top   ToC   RFC3196 - Page 83

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
Top   ToC   RFC3196 - Page 84

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
Top   ToC   RFC3196 - Page 85
   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
Top   ToC   RFC3196 - Page 86

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.
Top   ToC   RFC3196 - Page 87

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
Top   ToC   RFC3196 - Page 88

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
Top   ToC   RFC3196 - Page 89
   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.
Top   ToC   RFC3196 - Page 90
   [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.
Top   ToC   RFC3196 - Page 91

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
Top   ToC   RFC3196 - Page 92
   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
Top   ToC   RFC3196 - Page 93
   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
Top   ToC   RFC3196 - Page 94
   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
Top   ToC   RFC3196 - Page 95
   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.
Top   ToC   RFC3196 - Page 96

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.