2.1.6 Internet Printing Protocol (ipp)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

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

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Ned Freed <ned.freed@innosoft.com>

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:

Done

  

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

Done

  

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

Done

  

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

Done

  

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

Done

  

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

Done

  

Produce At least 2 implemented prototypes

Aug 97

  

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

Done

  

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

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

RFC2910

PS

Internet Printing Protocol/1.1: Encoding and Transport

RFC2911

PS

Internet Printing Protocol/1.1: Model and Semantics

Current Meeting Report

IPP WG - IETF 50th Plenary

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

He explained that because there was no meeting at the last Plenary, some of his presentation would span several months.

Agenda:
- Overview of all current IPP Internet-Drafts and where they are in the IETF process
- Review and comments on IPP Internet-Drafts, currently in IPP WG

Last Call
- Report from the IPP interoperability testing event Autumn 2000
- Future plans for IPP

1. Document Status
[IPP Project Time Line diagram]
1996: PWG Start
1997: IETF Start
1998: First bake-off
1999: IETF IPP/1.0, bake-off 2
2000: IETF IPP/1.1, bake-off 3
2001: IETF IPP/1.1 extensions

1999: RFCs 2565-69, 2639 - IETF Experimental:
- Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
- Mapping between LPD and IPP Protocols
- IPP/1.0: Model and Semantics
- IPP/1.0: Encoding and Transport
- IPP/1.0: Implementers Guide
- Design Goals for an Internet Printing Protocol

2000: IETF Standards Track:
- IPP/1.1: Model and Semantics - RFC 2911
- IPP/1.1: Encoding and Transport - RFC 2910
- IPP/1.1: Implementer's Guide [not Standards Track] - in IESG
- IPP: Requirements for Job, Printer and Device Operations [not Standards Track] - in IESG
- IPP: Job and Printer Set Operations - in IESG
- IPP: The 'collection' attribute syntax - in IESG
- IPP: Job and Printer Administrative Operations - in IESG
- IPP: LDAP Schema for Printer Services - in IESG
- IPP: Requirements for IPP Notifications [not Standards Track] - in IESG
- IPP: Event Notification Specification - in IESG
- IPP: Job Progress Attributes - in IESG
- IPP: The 'mailto' Notification Delivery Method - in IESG
- IPP: The INDP Notification Delivery Method and Protocol/1.0
- IPP: The 'ippget' Notification Delivery Method - in IESG

Ned Freed commented that most documents have gone thru IESG. IANA is having some confusion about how to handle some of the registries. Ned will coordinate with IANA to determine next steps. He also indicated that "things are fine."

Ned reported that Patrik Fältström is still working on the LDAP document-and he hopes that Patrik will finish his review soon.

IETF drafts currently in Last Call
- IPP URL Scheme <draft-ietf-ipp-url-scheme-02.txt>
- The 'indp' Delivery Method for Event Notifications and Protocol/1.0 <draft-ietf-ipp-indp-method-04.txt>
- The 'ippget' Notification Delivery Method for Event Notifications <draft-ietf-ipp-notify-get-02.txt>
- Printer Installation Extension <draft-ietf-ipp-install-02.txt>
- IPP URL Scheme
- The 'indp' Delivery Method for Event Notifications and Protocol/1.0
- The 'ippget' Notification Delivery Method for Event Notifications
- Printer Installation Extension

Carl-Uno asked for any comments about the above drafts.

Ned commented that a clear security section would be necessary.

There were no other comments on the drafts.

IPP Specifications that are PWG documents:
- IPP: Override Attributes for Documents and Pages IEEE-ISTO 5010.4
- IPP: Production Printing - Set 1 IEEE-ISTO 5010.3
- IPP: 'finishings" attribute values extension IEEE-ISTO 5010.1
- IPP: 'output-bin" attribute extension IEEE-ISTO 5010.2

Carl-Uno mentioned that some of these documents also generate additional IANA registration needs.

2. Report from the IPP Interoperability Testing Event Autumn 2000

Fifteen printer vendors participated in the IPP bake-off. Four firewall and proxy server vendors participated:
- 17 companies total
- 9 IPP client side implementations
- 16 IPP printer side implementations
- 96% IPP/1.1 client/printer success rate for interworking
- Firewalls and proxies worked fine
- A few issues:
* HTTP stack
* IPP/1.0 and IPP/1.1 interworking

Carl-Uno mentioned one problem experienced was that a 100 Continue was unexpectedly received. A few people, including Larry Masinter, agreed that no response should be sent until a request is received.

3. Market Activity with IPP
Carl-Uno gave some status on IPP products.

Canon, Ricoh, and Xerox have all introduced Multifunction products with IPP support.

New IPP Products in Japan from the following companies:
- Canon - printers, multifunction systems
- Epson - printers, small print servers
- Fuji Xerox - printers, multi-function systems
- HP - small print servers, network cards
- JCI - network cards
- Minolta - printers
- Ricoh - printers, multi-function systems

Europe:
- Axis, Sweden
- I-data, Denmark
- SEH Computertechnik, Germany

New IPP products - Linux
- Several vendors are now offering IPP Open Source code for Linux:
* Easy Software Products - CUPS
* Astart Technologies - LPRng
* VA Linux - GNUlpr
- Expect to see IPP code in most Linux distributions in 2001

New IPP products - Applications
- Easy Software Products
* IPP as transport for miniMAX international miniMax services competes with Kinko's and other printing shops
* IPP as printing service in the US Department of Defense
- From PrinterOn
* IPP for PrinterOn Internet Printing Services among Seybold Editors' Hot Picks in San Francisco 2000

IPP impact in other printing standards
- Universal Plug 'n' Play (UPnP) - Microsoft led consortium
- Wireless Printing in Bluetooth - Telecom consortium
- Job Definition Format (JDF) - CIP4 consortium on Production Printing
- IPP Fax - Printer Working Group project
- PPML - PODi (Print on Demand Initiative) consortium

4. Future plans for IPP
Remaining Work in the IETF IPP WG:
- Get the 4 WG Last Call drafts edited with any final comments and sent to the IESG
- Make one more revision of the IPP/1.1 Implementer's Guide to incorporate resolutions to a few issues from the latest bake-off and send to IESG
- Fix any issues brought up by the IESG or the RFC Editor
- Finish some IANA registrations for document types, etc.

Ned said that it is not necessary to create any RFCs for registering MIME types. It is especially easy if it is a vendor type.

Carl-Uno suggested to Ned that when the remaining documents can successfully be pushed through the IESG, he believes that the IPP WG will be ready to close.

5. HTTP Authentication
Scott Lawrence briefly referenced HTTP Authentication (RFC 2617) and Upgrading to TLS within HTTP/1.1 (RFC 2817).

After reviewing past IPP e-mail on security, Scott wanted to clarify some HTTP Digest Authentication Misconceptions.

Purposes of the Client Nonce (cnonce)
- Prevent chosen-plaintext attack
* Attacker spoofing server cannot choose all of the inputs to the authentication hash
* Incidentally protects against sloppy nonce choices by server
- Mutual authentication
* The client can check the response digest to verify that the server also knew the shared secret

Message Body Integrity Protection
- NOT algorithm=MD5-sess
* MD5-sess modifications shared secret usage to permit third party authentication services; has no effect on body integrity
- qop=auth-int
* Provides body integrity protection by incorporating body hash into authentication hash calculations
* Note that you don't know the authentication status until the end

Other
- A server can challenge any time it wants to
- For any reason it wants
- How can a server distinguish protection domains?
* Modify the realm name?

Carl-Uno requested that Scott should send his comments to the IPP e-mail list, given that many of the IPP participants were not at the Plenary.

Scott also mentioned that the HTTP reflector-although not very active-is still operating. He recommends that any HTTP questions should be directed to that list.

6. Fragmenting/Chunking XHTML/XML
Carl-Uno raised a last topic on Fragmenting/Chunking XHTML/XML to help deal with receivers that have limited resources. He mentioned that a few groups have been struggling with this issue recently. Two Internet-Drafts will be published in the near future:

- The MIME Multipart/Interleaved and application/chunk Content-types
* draft-herriot-multipart-interleaved-00
- The MIME Application/BatchBeep Content-type
* draft-herriot-application-batchbeep-00

Larry said that the problem really can't be solved-in general. He feels that neither of the above methods avoids the potential need to buffer at the receiver's end. If the receiver doesn't do the buffering, the sender must do the buffering at the receiver's request/control.

Predicting the optimal buffering order is a very difficult effort-even if it is within a single page.

The fundamental issue is not an encoding problem. It is related to the incremental rendering of a compound document by a device that cannot buffer all the components. This is very similar to the problem(s) being faced by mobile devices.

Ned: Have you considered "pull" instead of "push"?

Perhaps an IPP client could act as a server to pull the data when it is ready? There's nothing to stop you from having a reverse HTTP connection.

If MIME types are used for this approach, it would be appropriate to identify them for limited use only. For example, these types would not be appropriate for web browser support.

Larry referenced a W3C requirements document that discussed "packaging" components. It includes the concept of a manifest and several other features. He recommends examining this document as part of the effort to generate a possible solution.

Carl-Uno indicated that the group will need to consider whether it makes sense to try to solve this as an "object" problem, or if it is more appropriate to examine as a communication problem.

He also said that he does not think that he will be able to get travel authorization to attend the August IETF Plenary, but hopes to attend in December.

Meeting adjourned.

Slides

Agenda
HTTP Digest Authentication Misconceptions