Frequently asked Questions (FAQ) about the Internet Printing Protocol (IPP) project - Last updated: July 16, 1997 Q: What is the history of the IPP project? A: In the summer of 1996, Novell approached a number of companies to find out if they were interested to participate in a printing protocol project for the Internet. Xerox and others expressed some interest and suggested that the first step would be to develop a draft text and decide how to initiate the project. As result, a first draft document was developed in cooperation between Novell and Xerox. At this stage, the project was known as Lightweight Document Printing Application (LDPA). In a parallel effort, IBM had started working on a proposal for Internet printing using Web technology, under the name of HyperText Printing Protocol (HTPP). It was also known that Microsoft and HP had started work on a solutions for a new generation of print services for NT 5.0. In parallel to the writing of initial draft texts, it was investigated how to start up the public standardization project. It was clear from the beginning that the initiators wanted the project to become an acknowledged project with the Internet Engineering Task Force (IETF), but first needed to get together a forum of experts before suggesting it to the IETF. The choice was to start the activity in the Printer Working Group (PWG), a group of people with representation from printer and print server vendors, which had previously developed the IETF Printer MIB specification. After initial discussions in a couple of earlier meetings, the PWG started the IPP project in November 1996. Carl-Uno Manros from Xerox was chosen as the project chair and Scott Isaacson from Novell as the main editor. Steve Zilles from Adobe was later added as the IETF co-chair, and Don Wright from Lexmark, Bob Herriot from Sun and Roger deBry from IBM as further editors. After some discussion, it was decided to pool the earlier efforts from Novell/Xerox and IBM into what is now named the Internet Printing Protocol (IPP) project. Some 20 companies involved with printers and/or print servers confirmed that they were interested in participating. After negotiation with the Application Area Directors in the IETF, it was decided to hold a birds-of-a-feather (BOF) session for IPP in the December 1996 meeting of the IETF. The outcome of that meeting confirmed that there was widespread interest in developing a printing protocol for the Internet. Q: What is the current Status in the IETF? A: The IPP project was accepted by the IESG as a new WG of the IETF on March 6, 1997 after which the WG charter was a bit further polished and published later in March. The reference to the charter is: http://www.ietf.org/html.charters/ipp-charter.html Q: What is the scope of the IPP project? A: The IETF WG Charter text, describes the project (IPP version 1) as: There is currently no universal standard for printing. Several protocols are in use, but each has limited applicability and none can be considered the prevalent one. This means that printer vendors have to implement and support a number of different protocols and protocol variants. There is a need to define a protocol which can cover the most common situations for printing on the Internet. The goal of this working group is to develop requirements for Internet Printing and to describe a model and semantics for Internet Printing. The further goal is to define a new application level Internet Printing Protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job The Internet Printing Protocol is a client-server type protocol which should allow the server side to be either a separate print server or a printer with embedded networking capabilities. The focus of this effort is optimized for printers, but might be applied to other output devices. These are outside the scope of this working group. The working group will also define a set of directory attributes that can be used to ease finding printers on the network. The Internet Print Protocol will include mechanisms to ensure adequate security protection for materials to be printed, including at a minimum mechanisms for mutual authentication of client and server and mechanisms to protect the confidentiality of communications between client and server. Finally, the IPP working group will produce recommendations for interoperation of LPR clients with IPP servers, and IPP clients with LPR servers. These recommendations will include instructions for both the translation of the LPR protocol onto IPP and the translation of the IPP protocol onto LPR. However, there is no expectation to provide new IPP features to LPR clients, nor is there an explicit requirement to translate LPR extensions to IPP, beyond those features available in the 4.2BSD UNIX implementation of LPR, and which are still useful today. Q: If this is version 1 of IPP, what is intended for inclusion in future versions? A: Other capabilities that will be examined for future versions include: - features needed by administrators and operators of a printing system - notifications from the server to the client - accounting - commercial transactions for printing of documents Q: What subjects are out-of-scope for the IPP project? A: Subjects currently out of scope for this WG are: - property rights - fax input - scanning Q: Will this effort be coordinated with printing standards efforts in other groups? A: The IPP working group will strive to coordinate its activities with other printing-related standards bodies, without the need to be strictly bound by their standards definitions. These groups are: - ISO/IEC JTC 1/SC 18/WG 4 on Document Printing Application (ISO/IEC 10175 parts 1-3) - The Object Management Group (OMG) on OMG Printing Facility (proposals from Xerox and Ricoh under evaluation) - IEEE (POSIX System Administration - Part 4: Printing Interfaces) - X/Open (Printing Systems Interoperability Specification) - but it looks like this specification will be dropped - The Printer Working Group Q: There is already an Internet printing standard defined in RFC 1179, also known as LPD - Why are you developing a new one? A: If you look a little more carefully at RFC 1179 you will find that it is just an informational RFC, intended to document a commonly used, but proprietary set of functionality for Unix machines. It was never intended for the Internet Standards Track. Many vendors have used the RFC 1179 as a starting point for implementations, but have then added their own proprietary extensions to it up to a point where there is now no more meaningful to talk about RFC 1179 as even a "de-facto" standard. All active participants in the project have declared that they consider RFC 1179 to be useless as the starting point for IPP. However, one of the documents to be produced by the IPP WG is a mapping between LPD and IPP. Q: What is the Document Printing Application (DPA)? A: DPA is an ISO standard for printing (ISO/IEC 10175) that has been worked on for a number of years, and was finally published in 1996. DPA has a lot of printing functionality defined, probably more than anybody will ever implement in a product. Even if DPA can be seen as a bit of an overkill, it does provide a lot of useful input to any project that works on printing. Several experts in the IPP project have been active in the specification of DPA and can leverage experience from that project. Semantically, IPP can be seen as lightweight version of the functionality covered in DPA, with some new features thrown in, but the syntax, protocol stack etc. will be different in the Internet environment. Q: What documents are the IPP project planning to develop? A: The currently proposed texts are: - Requirements for Internet Printing (Informational) - Internet Printing Protocol/1.0: Rationale (Informational) - Internet Printing Protocol/1.0: Model and Semantics (Standards Track) - Internet Printing Protocol/1.0: Protocol (Standards Track) - Internet Printing Protocol/1.0: Security (Standards Track) - Internet Printing Protocol/1.0: Directory Schema (Standards Track) - Mapping between LPD and IPP Protocols (Informational) Q: How can I get involved in the IPP project? A: You can get information and participate over the Internet in the following ways: General Discussion DL: ipp@pwg.org To Subscribe to the DL: ipp-request@pwg.org Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Web-site: http://www.pwg.org/ipp In addition, the PWG organizes face-to-face meetings in the US about every 6 weeks, and also holds frequent telephone conferences. Announcements about these are given over the IPP DL. Please note that the PWG organized meetings and phone conferences are not considered part of the formal IETF process and that all decisions in such meetings or phone calls are subject to further discussion and resolution on the IPP mailing list. However, many of the more active project participants do attend the PWG organized events. If you are new to the project, the best starting point is our Web pages, which contain pointers to everything else you need to know about the project. Q: How is the work in the IPP project currently organized? A: The formalities in the IETF have not held up the actual work in the PWG. One-day to two-day meetings were held in January, February, April, May and June 1997 with an increasing number of participants. The February meeting had 45 people attending, representing most of the American and Japanese printer and print server vendors and also included representatives from Microsoft and Netscape. In addition to the face-to-face meetings, weekly phone conferences and intensive discussions over email are held. The project has established six subgroups, which work on different aspects of the specifications, the first five of which are expected to produce an RFC document as output: - REQ - Requirements & Scenarios - MOD - Model & Semantics - DIR - Directory schema - PRO - Protocol - SEC - Security - TES - Prototyping & Testing Several companies have set up IPP prototyping teams: Adobe, Byas, Canon, IBM, Novell, Sharp, Underscore, Xerox, Xionics and Zenographics. Other are expected to follow. Q: If you are going to use HTTP as a basis to transfer IPP, would you then base it on HTTP 1.0 so that all current browser implementations can be used? A: The HTTP/1.0 protocol is considered bad because it uses a separate TCP connection for each file transferred. In the context of the World Wide Web where most transfers are short, HTTP/1.0 is tremendously inefficient. Also, a link which carries large numbers of short-lived TCP sessions is likely to become highly saturated, because the set-up and tear-down sequences are not affected by TCP's "slow-start" and congestion avoidance algorithms -- hosts send these packets at the same rate regardless of how congested the link is. Essentially the "overhead" packets "crowd out" those used for payload until the link is useless. Version 1.1 of HTTP, which is now on the official Internet Standards Track, is an appropriate standard to reference - see RFC 2068. The single most important improvement in HTTP/1.1 is its ability to perform multiple transfers in a single TCP connection. According to tests done by the W3C, HTTP/1.1 is a significant improvement over /1.0 at both network efficiency and response time. For further background information, please read the IPP Rationale document. Q: Why don't you specify your own IPP protocol directly on top of TCP/IP? A: This has been seriously discussed and is still considered an option by some group members. The majority of active participants still seem to favor using some flavor of HTTP over making our own, under the assumptions that introducing a new protocol will take longer to reach the market and might prevent implementers from using some of the infrastructure, tools, etc. that are already in place for HTTP and Web-browsers/servers. The latest discussions seem to indicate that the group wants to make a first mapping of IPP on top of HTTP 1.1, well aware of its potential drawbacks. A contributing factor is that printer and print server vendors are already building HTTP into their products foer a number of other functions such as configuration, management and online manuals. Some hope is attached to the new HTTP-NG project, which is expected to develop a replacement for HTTP over the next couple of years. IPP could then be mapped to the new protocol, which is expected to deliver a better and more reliable transfer service, which is also expected to be better suited to the IPP requirements. Q: Will you define the IPP operations in MIME format, so that IPP can be easily mapped to store-and-forward protocols like SMTP? A: We have defined our own MIME type called "application/ipp" as part of the protocol mapping. This will be encoded in the HTTP style of RFC 2068, rather than in SMTP style. The "application/ipp" type is used as general container for each of the operations and their responses. Q: What is the Simple Web Printing (SWP) proposal from Microsoft and HP and how will that impact the Internet Printing Protocol? A: The PWG was submitted to the IPP group in May and was extensively discussed in a PWG IPP meeting in San Diego on May 15, 1997. The intention with the proposal was to define a leaner subset of IPP, based on the IPP Model & Semantics. After rather intensive discussions, features from the SWP proposal are now integrated in the overall IPP solution. In the process, the group decided to restructure some of the operations and to make some of them optional, but it should be noted that the SWP was never intended as an alternative or competing solution to IPP. Q: Why are you only defining a Directory Schema for directory support - Won't you need a protocol to actually implement it? A: Very true. The PWG originally suggested a directory specification using the Lightweight Directory Access Protocol (LDAP), however the IETF Area Directors wanted to limit the IETF specification to a schema at this stage. The schema could then be mapped to DNS, LDAP, or commonly used proprietary directory protocols. The prototyping subgroup still needs to agree which protocol to use for inter-operability testing. Q: What is the current schedule for the IPP project? A: The PWG had an initial, very aggressive, schedule to have a set of specifications stable within 6 months (= May 1997). This has turned out to be too optimistic and the current plan is to have all documents ready for review in the Munich IETF in August 1997, followed by final editing and submission to the IESG in September 1997. A major difference compared to some earlier standardization projects, is that we now prototype as we go along to ensure the functionality of the specifications and try to avoid inefficient solutions. --- Carl-Uno Manros - Co-chair IETF IPP WG - July 16, 1997