2.1.7 Internet Printing Protocol (ipp)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98


Carl-Uno Manros <manros@cp10.es.xerox.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ipp@pwg.org
To Subscribe: ipp-request@pwg.org
Archive: ftp://ftp.pwg.org/pub/pwg/ipp/

Description of Working Group:

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 Print 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.

Other capabilities that will be examined for future versions include:

- security features for authentication, authorization, and policies - notifications from the server to the client - accounting

Subjects currently out of scope for this working group are:

- protection of intellectual property rights - fax input - scanning

The working group shall 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 (in development) - IEEE (POSIX System Administration - Part 4: Printing Interfaces) - X/Open (Printing Systems Interoperabilty Specification) - The Printer Working Group

Goals and Milestones:

Mar 97


Submit Internet Printing Protoco/1.0: Model and Semantics as an Internet-Draft.

Mar 97


Submit Internet Printing Protoco/1.0: Protocol as an Internet-Draft.

Mar 97


Submit Internet Printing Protocol: Requirements and Scenarios as an Internet-Draft.

Mar 97


Submit Internet Printing Protoco/1.0: Directory Schema as an Internet-Draft.

Apr 97


Review of specification in IETF meeting in Memphis, TN, USA

May 97


Produce At least 2 implemented prototypes

Aug 97


Submit other Internet-Drafts to IESG for consideration as Proposed Standards.

Aug 97


Submit Internet Printing Protocol: Requirements and Scenarios I-D to IESG for publication as an Informational RFC.


No Request For Comments

Current Meeting Report

Internet Printing Protocol (IPP) WG -- Dec 9, 1998

Notes taken by Lee Farrell.

Carl-Uno Manros led the meeting. Around 40 people attended, only four of which were regular IPP WG members. Many people from the Internet Fax group were present.

The group's mail list and website address are:
- ipp@pwg.org
- www.pwg.org/ipp

Carl-Uno presented the planned agenda topics:
- IPP documents
- IFax over IPP
- IPP security

1 IPP Documents

Carl-Uno explained that the Printer Working Group members have several implementations of IPP as defined in the latest versions of the Working Group's documents. They have been submitted for acceptance as Informational RFCs, and collectively define IPPv1.0:
- draft-ietf-ipp-req-03.txt
- draft-ietf-ipp-req-rat-04.txt
- draft-ietf-ipp-req-mod-11.txt
- draft-ietf-ipp-req-pro-07.txt
- draft-ietf-ipp-req-lpd-ipp-map-05.txt

Carl-Uno reported that the Application Area Director had agreed to propose to the IESG that the documents be progressed as Informational RFCs - primarily to document the existing implementations. Other features will be required before the documents will be submitted for standards track.

Another document that the group has written is an Implementor's Guide, -implementers-guide-00.txt. It is primarily being written to offer hints and/or advice on topics that are relevant to people developing implementations. This document will be further updated and then sent to the IESG after WG review and last call.

The document that describes a proposed IPP URL scheme is draft-ietf-ipp-scheme-00.txt.

Keith Moore said that the IESG will be reviewing the documents "soon." He admitted that he has not yet reviewed them, and will be traveling or on vacation for the rest of this year. [He did not seem to be very confident in predicting when the documents might actually get issued (or accepted?) as Informational RFCs.]

Randy Turner asked if the work on "IPP New Version" should come from a new Working Group. Keith Moore suggested that any WG that has existed longer than 18 months should consider closing down their activity-and consider developing a different Charter for subsequent WG activity.

2 IPP Security

Randy Turner presented the following information pertaining to IPP Security methods:
- Existing methods available as IPPv1.0 security options
- Proposed "IPP New Version" security method: TLS via:
- HTTP Upgrade Header a possible mechanism could involve selection via URL parameters,e.g. ipp://printer.com/SECURITY="TLS"/...

One of the attendees said that having parameters in the URL defeats the whole purpose of having a unique URL scheme.

There was some discussion about the number of "round trip" communications needed for different security alternatives.

3 IFax over IPP

Richard Shockey presented his document, draft-shockey-ipp2ifax.01.txt, that discusses IPP as an Internet Fax Service. The mail list on the subject is: ifx@pxw.org. (To subscribe, send an e-mail message to majordomo@pwg.org with a message body of: "subscribe ifx <your e-mail address>".)

At a high level of abstraction, one could say that Fax is similar to remote printing. IPP meets the test of a facsimile service.

- IPP is realtime... the "look and feel" traditional Fax
- Unrestricted output quality
- Say goodbye to your phone company-local exchange carrier line charges are high for Fax
- Never busy Fax-although low end devices...

What needs to be done to IPP?
- Satisfy legal and "custom and practice" requirements
- TIME/DATE logging of transactions by client and server locally for receipt and ack
- Fax profile for IPP client behavior
- Watermarking
- cover page
- Sender identity exchange? (CSID vs. vCard)
- Gateway to GSTN-FAX and/or RFC 2305-Ifax
- attribute mapping - TIFF type
- attribute definitions - Relay Mode
- Other
- Automatic Printer Driver Download
- Security
- IPP scheme

IPP Server as a Gateway
- Redirection server
- open server-anyone can send
- redirection address known by server
- Relay server
- closed server-access by Digest Auth
- redirection address passed on wire by IPP attributes to be defined

Recommendations: IPP Action Items
- Document goals and objectives baseline with scenarios
- Document IPP client/server profiles
- Document IPP to IFax/Fax attributes and mappings
- Investigate which portions of RFC 2301 should be used as requirements
- Continue work on IPP Enhanced Notifications-output/redirection
- Recruit IFax WG members

4 Audience Comments

Several comments involved explanation of either the existing Fax requirements or IPP capability.

Herman Silbiger claimed that the two major differences between IFax and IPP are that IFax:
- uses an (unalterable) image description of a document
- contains sender id information

Carl-Uno mentioned that in a conference organized by the Multifunction Peripheral Association (MFPA) considerable interest was shown in IFax over IPP because vendors anticipate the need to implement both IPP and IFax capability within multifunction peripheral devices.

There were various philosophical statements and opinions about how society treats faxed messages.

Herman believes there wouldn't be any objection from the ITU world if IPP "encroaches into Fax transmission."

The IPP WG will be meeting in San Diego next week, and people are encouraged to attend if they want to help work on this effort.

Keith Moore suggested that a separate IETF WG could be chartered to work on the integration of IPP and IFax. Several people indicated that they are willing to participate in such a Working Group. We should plan to hold a "Birds of a Feather" (BOF) session during the next IETF meeting.


None received.