2.1.7 Internet Printing Protocol (ipp)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00

Chair(s):

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC2565

E

Internet Printing Protocol/1.0: Encoding and Transport

RFC2566

E

Internet Printing Protocol/1.0: Model and Semantics

RFC2567

E

Design Goals for an Internet Printing Protocol

RFC2568

E

Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol

RFC2569

E

Mapping between LPD and IPP Protocols

RFC2639

 

Internet Printing Protocol/1.0: Implementer's Guide

Current Meeting Report

Note taker: Lee Farrell

Carl-Uno Manros, Chair, led the Internet Printing Protocol (IPP) WG session.
Around 30 people attended.

Carl-Uno listed the IPP/1.1 documents that are still under review by the IESG:
- Model and Semantics
- Encoding and Transport
- Implementer's Guide

He noted that although there have been some recent updates on these documents, the changes have been editorial in nature, the technical content has remained the same since the documents were submitted in June 1999.

He also listed the new IPP Notification drafts:
- IPP Event Notification Specification
- The "mailto:" Notification Delivery Method
- The "ipp" Notification Polling Method
- The "INDP" Notification Delivery Method
- IPP Notification Delivery Protocol (INDP protocol)
- Notifications over SNMP

Bob Herriot then presented some slides about issues using HTTP "chunking" with regard to notification messages. He first asked the group whether HTTP proxies support chunking:
- for POST in requests?
- for POST in responses?

But none of the attendees could provide an answer.

As a brief background, Bob explained that subscriptions for both printer and job events contain the notification recipient URL. The event notification is intended to be delivered to the specified recipient URL whenever the event occurs. Currently, there are four different delivery methods currently under consideration:
- ipp-get:
- indp:
- mailto:
- snmp-notify:

In the ipp-get method, the Printer saves each event for a fixed amount of time. The client must poll for event notifications within this time interval. When polled, the Printer responds to the client with one or more event notifications and a recommended time (lease time) by which the client should next poll.

Bob raised a few issues:
- In order for the client to receive events as they occur, should there be an operation with a single HTTP POST, returning event notifications in multiple response-parts spread over a long duration of time (e.g., several minutes)?
- Should this operation use HTTP GET instead of POST?

Although there was some discussion of the first two items, several people in the group felt that the appropriate experts were not present to adequately address this question. Later, Keith Moore suggested, "Try it - it might work." However, it was noted that intermediaries on the network might prevent it from being a reliable method.

- Should each response-part be a separate message body in MIME multi-part?

Keith Moore suggested that this should not be done. He recommends that the group should "avoid the complication."
- Do the lease and server recommended times make this polling mechanism a reasonable alternative to Printer-initiated event delivery methods (i.e. mailto, indp, and snmp-notify)?

The last question caused Keith Moore to raise a concern that if multiple notification delivery methods are used within IPP, it is very likely that a user will experience widely differing behavior - depending on the method employed. He recommended that perhaps the group should concentrate on a single method of event notification. When asked which one, Keith suggested that ippget might have the best chance of working in most environments. He also suggested that ippget would require less code (no additional protocols), but might require more cache/memory - for storing events. This could be lessened by using shorter time intervals, causing fewer events to be saved at one time.

Carl-Uno noted that the group consensus seems to be that support of ipp-get is favored as the baseline delivery method. The mailto method might be a secondary increment.

Carl-Uno then referenced the Internet-Draft proposal for an LDAP schema for printer services: draft-ietf-ipp-ldap-printer-schema-00.txt. He noted that this document is aligned with the SLP printer template: draft-ietf-svrloc-printer-scheme-06.txt

He listed the new Internet-Drafts on additional IPP operations and syntax:
- Job and Printer Set Operations: draft-ietf-ipp-job-printer-set-ops-01.txt
- The 'collection' attribute syntax: draft-ietf-ipp-collection-02.txt

Carl-Uno referenced that at the previous IETF Plenary in November he led a BOF session for IPPExt. At that meeting, the group proposed additional future work for the IPP WG. As a result of that meeting, a proposed Charter was submitted to the IESG for an IPP Extensions Working Group. He said that he has not yet received any response about forming a new WG.

The proposed Charter contains two areas of focus for future activity in the IPPExt WG.
The proposed Milestone deliverables are:
- New Operations - June 2000
- Notifications - September 2000

Before the meeting ended, Carl-Uno expressed his idea of making available "open source IPP client(s)" for full support of IPP. He mentioned that Microsoft is only supporting the bare minimum of the IPP feature set in their client. He would also like to see clients that work on other operating systems besides Windows. If anyone,or any company, is interested in working on this goal, please contact Carl-Uno.

IPP meeting adjourned.

Slides

None received.