NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Carl-Uno Manros <cmanros@cp10.es.xerox.com>
Steve Zilles <szilles@adobe.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Keith Moore <moore+iesg@cs.utk.edu>
General Discussion:ipp@pwg.org
To Subscribe: ipp-request@pwg.org
Archive: ftp://ftp.pwg.org/pub/pwg/ipp/
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 that 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 Interoperability Specification)
- The Printer Working Group
Goals and Milestones:
· Requirements for an Internet Printing Protocol
· Internet Printing Protocol/1.0: Model and Semantics
· Internet Printing Protocol/1.0: Directory Schema
The meeting was called to order by Carl-Uno Manros at 9:03 AM CST on April 8th at the Peabody Hotel in Memphis Tennessee.
I. Introduction of Working Group Charter and Internet-drafts
Carl-Uno reviewed the Working Group charter including the lists of:
The goals and background information of the charter were then reviewed. (Carl-Uno's charts will be available as a part of the proceedings). A question was asked as to what directory methods would be used. The current plan is to define the directory schema to be directory neutral and to be optional. Since the original IPP BOF at the last IETF meeting, significant security requirements have been added to the charter. A question was raised as to how the directory information would keep up-to-date when used in a cached environment. Since IPP is not defining the directory access method, only the schema, IPP will not be addressing the area of caching of directory information. Many people felt that the directory work should be a milestone after the protocol is done; however, there were others concerned that while the actual document could be done later, it needed to be considered while working on the model. The Working Group will produce recommendations for inter-operation between IPP clients/servers and LPD clients/servers.
March 97: Internet Drafts: requirements, model, protocol, and directory schema
May 97: Several implemented prototypes
August: Requirements I-D to IESG as informational RFC
Mapping IPP/LPR mapping as informational RFC
Other documents submitted as RFCs
Discussion list is ipp@pwg.org.
To subscribe: ipp-request@pwg.org
Archive is ftp://ftp.pwg.org/pub/pwg/ipp
Web Server is http://www.pwg.org/ipp/
A long discussion on what should be covered within the directory schema. One of the major potential problems identified was how to include access control as a part of the information available through the directory. The scope of IPP at this time does not cover administrative functions like job accounting.
Steve Zilles presented an outline of the general direction the group is going towards in the area of "protocol." (Steve's charts will be a part of the proceedings.) A concern was raised that if multiple, alternative ways are defined to do something, we will fail. This comment was directed at the current direction to perhaps support Application/IPP and Multipart/FormData as well as support both HTPP/1.1 and some new IPP TBD. The current protocol issues Steve identified are:
1) Status inquiries during data transmission
2) What must the server implement?
IPP subset of HTTP/1.1 (non-caching, origin server)
Can we really subset HTTP/1.1?
Work level difference between creating a new protocol versus subsetting?
Harald Alvestrand presented a concept of layering and a HTTP/HTML presentation of data to be send via or received from an IPP protocol.
Interoperability issues with potentially two protocols and syntaxes are:
1) One protocol, two syntaxes. Server must implement both.
2) Two separate protocol: formdata over HTTP or application/ipp over tbd, server may implement either
3) Does the request format determine the response format?
4) How are the operations coded? In the formatted data, in the protocol header, and in the URL that is the target?
Carl-Uno presented the work being done on security for IPP. (These charts will be available in the proceedings.) The type of attacks that could be deployed against IPP were described including masquerading, eavesdropping, tampering, replaying, denial of service, document malicious content code (embedded programs in the print job), liability and provability of service. All these were mapped against security services like client authentication, server authentication, data confidentiality, data integrity, non-repudiation and timestamping/nonces. Some areas of the chart need to be updated with an additional "yes." "Signing" was identified as something that has been very useful as a combination of authentication and integrity.
The group has looked at a number of security services being investigated including HTTP/1.1 (Digest Authentication -- RFC 2069), SSL(V2), SSL(V3) and LDAP. Additional security service suggested to be examined includes HTTP, SMIME and PGP.
Simple security service (like LPD user name) would probably not be appropriate for a Standards Track Document (Keith Moore.) Adequate security must be defined but the security level may be negotiated between the client and the server.
Harald A: Decisions on security should be made by the Working Group not by the Area Directors, but having no security will probably be a problem.
IV. Model Document
Harald A. expressed his opinion that while the model document is very large, it seems incomplete. He had several comments and will document them in detail to the distribution list.
Due to a lack of time, the Requirements Document was not discussed.
The meeting was adjourned at 11:35AM CST.