2.1.6 Internet Printing Protocol (ipp)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99

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

Current Meeting Report

IETF45 - IPP WG Session - July 14, 1999

The meeting was attended by a little more than 20 people, many of which came from the Internet Fax WG.

Lee Farrell was the note taker.

Carl-Uno Manros led the meeting and provided the agenda:
- Update on project status
- Remaining work within the current charter

- IPP WG Charter update
- Possible future work on IPP

IPP Notifications
Carl-Uno briefly referenced the IPP Notification activity:
- Notification requirements for IPP <draft-ietf-ipp-not-02.txt>
- Notification solutions for IPP in progress - no Internet-Draft yet

He gave a description of the Notification Requirements "Overall Model" (see diagram below.) He pointed out that IPP Notifications would be an optional part of the protocol.

Legend:
A = Client and Notification Recipient
B = Notification Recipient (subscription by some third party)

O A +----------+ Create Request with ###########
/|\ | client/ |----Subscriptions------------># IPP #
/ \ | notif. | # Printer #
end- | recip. |<---Job and Printer ----------# Object #
user +----------+ Notifications ###########
/
O B +----------+ /
/|\ | notif. | /
/ \ | recip. |<---Job and Printer -------+
end- | | Notifications
user +----------+

He then provided a few scenarios that illustrate the uses of IPP Notification, and serve as the basis for various requirements.

Scenario 1
- I am sitting in my office and submit a print job to the printer down the hall. I am in the same security domain as the printer and geographically near. I want to know immediately when my print job is completed (or if there is a problem) because the document I am working on is urgent.

Scenario 2
- I am working from home and submit a print job to the same printer as in the previous example. However, since I am not at work, I cannot physically get the print file or do anything with it. It can wait until I get to work this afternoon. However, I'd like my secretary to pick up the output and put it on my desk so it doesn't get lost or miss-filed. I'd also like a queued notification sent to my email so that when I get to work I can tell if there was a problem with the print job.

Scenario 3
- I am sitting in my office and submit a print job to a client at an engineering firm we work with on a daily basis. The engineering form is in Belgium. I would like my client to know when the print job is complete, so that she can pick it up from the printer in her building. It is important that she review it right away and get her comments back to me.

Carl-Uno mentioned that the notification should be available in two different formats - one for machine consumption, and one for "human readable."

Scenario 4
- I am in a hotel room and send a print job to a Kinko's store in the town I am working in, in order to get a printed report for the meeting I am attending in the morning. Since I'm going out to dinner after I submit this job, an immediate notification won't do me much good. However, I'd like to check in the morning before I drive to the Kinko's store to see if the file has been printed. An email notification is sufficient for this purpose.

Scenario 5
- I am printing a large, complex print file. I want to have some immediate feedback on the progress of the print job as it prints.

Scenario 6
- I am an operator and my duties is to keep the printer running. I subscribe independently from a job submission so that my subscription outlasts any particular job.

Scenario 7
- I am an printer statistics application. I subscribe independently from a job submission so that my subscription outlasts any particular job. My subscription may persist across power cycles.

There is still much debate regarding scenario 7. Many people in the group are concerned about any scenario that might imply support for accounting capabilities. The requirements for such support would be much more difficult for guaranteeing the necessary reliability (and security?) required for accounting applications. Some people think it is desirable.

There are two variations of the Notification Subscription:
- As part of IPP Job Submission (for single Job)
- As independent Operation (for Printer and all Jobs)

Also, there are two possible formats for the Notification:
- Machine friendly: application/ipp MIME format
- Human readable: text format (e.g. email)

Bob Herriot pointed out that an additional subscription capability is being considered. It would be possible to specify an individual job, and receive notifications only related to that job.

Additional items that still need consideration and further discussion:
Notification transport:

Other notification criteria:

Carl-Uno provided a list of the Job Notification content items:
- version-number
- status-code
- request-id
- job-printer-uri
- job-id
- job-trigger-events
- job-trigger-message
- job-trigger-time
- job-trigger-date-time
- job-state
- previous-job-state
- job-state-reasons
- previous-job-state-reasons
- subscription-id

The concept of using "multi-part alternative" as a possible format was raised. This will be investigated further.

He also provided a list of the Printer Notification content items:
- version-number
- status-code
- request-id
- printer-uri-supported
- printer-trigger-events
- printer-trigger-message
- printer-trigger-time
- printer-trigger-date-time
- printer-state
- previous-printer-state
- printer-state-reasons
- previous-printer-state-reasons
- subscription-id

Carl-Uno asked the group if anyone had any opinions about whether or not the group should attempt to support accounting requirements. One opinion was expressed: "I think the whole idea of push-based accounting is a bit weird."

Keith Moore stressed that whatever choice was made, he wants it to be optional. He later advised that the group should first concentrate on "the lightweight version" of collecting statistics, rather than attempting full support for a reliable accounting system.

Bob Herriot provided some conclusions and issues that were discussed at the previous IPP meeting (held in Copenhagen a week earlier):
- Sequence ids will be added to notifications
- When processing gets "busy", notification service may degrade; IPP will not allow the client to request "high quality service"
- The concept of subscription "leases" will be used. The server will decide the length of a lease (less than or equal to the period requested by the client.)
- For job-related subscriptions, the lease will last for the duration of the job.
- Subscription lease information should be maintained (if possible) over a power recycle
- Duplicate subscriptions will be allowed. A Printer might suppress duplicate notifications.

There was a long discussion about using UDP-based protocols that don't have congestion control. Generally speaking, this is undesirable - but it is only meaningful for communication of "lots of data". For "per page" event notification, it is suggested that TCP connections should be used. Should the client be required to support both-and select the appropriate one? Or maybe a TCP connection should always be used?

It was noted that the Fax community "really likes" reliable page-based notification. There is a desire to know, for example, that out of 50 pages sent, only 49 were completed.

Will an environment that can accept print jobs be so asymmetric that notifications might get lost? Is the entire issue of "real-time vs. reliability" truly an appropriate concern for this situation?

One person suggested that TCP should be implemented first-and only after reasonable experience is gained should the question of using UDP be revisited.

Charter Updates
Carl-Uno noted that the Charter contents are in serious need of update. The following items were identified:
- Finalization of IPP/1.1 documents on:

- IPP/1.1 Implementer's Guide Oct 1999
- Requirements for IPP Notifications Oct 1999
- IPP Notifications Specification Q1 2000
- Wrap up Current Charter Q2 2000

Future Work
A few items have already been identified for "next phase" IPP activity:
- Additional Operations for Administration
- Additional Features for Production Printing

Carl-Uno has asked Keith Moore for advice on whether the above topics should be pursued outside of the IETF or under a re-chartered (new?) Working Group activity. Unfortunately, Keith had left the meeting before he could respond.

Meeting adjourned.

Slides

Agenda