Chair(s):
Steve Zilles <szilles@adobe.com>
Carl-Uno Manros <manros@cp10.es.xerox.com>
Applications Area Director(s):
Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Keith Moore <moore+iesg@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 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:
| 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 Printing Protocol/1.0: Model and Semantics
· Internet Printing Protocol/1.0: Directory Schema
· Internet Printing Protocol/1.0: Security
· Mapping between LPD and IPP Protocols
· Internet Printing Protocol/1.0: Protocol Specification
· Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP)
Chairs: Carl-Uno Manros and Steve Zilles
The Monday session was attended by about 35 experts and the Wednesday session by about 25. A total of 48 experts signed up on the attendance sheet. All of the WGs Internet-Drafts were open to review and comments.
I. Session on Monday, August 11 (minutes taken by Randy Turner)
Carl-Uno Manros opened the meeting and reviewed the agenda.
The I-D: <draft-ietf-ipp-req-00.txt> Requirements for an Internet Printing Protocol was briefly introduced. This document will need some updating to align with more recent documents, otherwise no comments.
Steve Zilles then briefly provided a quick overview of IPP, specifically the object concept.
The I-D: <draft-ietf-ipp-rat-01.txt> Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol was briefly discussed, limited to the model aspects, without any substantial comments.
The I-D: <draft-ietf-ipp-model-04.txt> Internet Printing Protocol/1.0: Model and Semantics was introduced by Scott Isaacson. This is the key document for IPP and still contained a number of open issues. Scott had prepared proposed resolutions to all the issues flagged, based on WG input since the draft was published. Most of the proposed resolutions were uncontroversial, but the following raised some discussion:
1. Compression of IPP messages
This issue is OPEN. The WG is looking at other standards and existing enumerations for compression algorithms.
2. Alignment with Job Monitoring MIB
job-k-octets, job-impressions, and job-media-objects will be aligned semantically with the Job Monitoring MIB.
One note about the Job Monitoring MIB. Keith Moore, Area Director for Applications, noted that there is no formal IETF working group chartered for the Job Monitoring MIB effort. Further, there may be problems with IPP documents achieving "proposed" status if IPP documents reference such other documents. He reiterated that the Printer Working Group had submitted an extension to the Printer MIB working group's charter to include the Job MIB, but that the request had not been processed by the IESG, so there may be a problem here.
3. Human Language and Character Set
IPP mandates UTF-8 for application/ipp messages. HTTP Accept-Headers will be used for human-language attributes. Questions from the audience asked about whether the WG had considered the use of an updated Unicode spec. UCS-4 which is currently being proposed. Scott Isaacson implied that the WG is open to suggestions as to what standard should be applied here. The basic theme echoed by Keith Moore was to try and follow Harald Alvestrand's document, and if better methods are suggested, the IESG will keep an open mind.
4. Job-URI Attribute
"A lively discussion ensued." Basically, it was agreed that this issue is still OPEN and will be discussed on the mailing list.
5. Use of "Conditionally Mandatory" in IPP documents.
The I-D will be re-edited to focus on what must be implemented in order to realize certain specific functional components. Keith Moore reflected on current IETF documents for keywords such as MUST, SHOULD, MAY, etc. and that the WG should try and follow the IETF guidelines and best current practice with regards to such conformance/compliance vocabulary.
6. Use of MIME types for "document-format"
Currently, the model document specifies the use of Printer MIB enumerations for specification of document-format. In addition, at a recent PWG meeting, it was agreed that enumerations for PDF and HTML ought to be added to this list.
Upon hearing the proposed alignment with the Printer MIB for these values, "a lively discussion ensued."
It was the opinion of Larry Masinter (chair of HTTP WG), Keith Moore, and most of the IETF audience that alignment with the Printer MIB was a mistake, and that we should focus on sticking with MIME-type specifications.
Further, Keith Moore went on to say that the current draft of the Printer MIB was "broken", and that he is seriously considering delaying advancement of the Printer MIB draft until this (and possibly other) issues are addressed. Keith did not go into any detailed analysis of why the MIB was broken, but seemed to suggest that there were more than one reason why it's broken. He went on to say that its possible that (ironically) the IESG might suggest to the working group that the Printer MIB should align itself with the MIME-types and change the way that interpreters are enumerated in the MIB. He suggested that the group should consider strings, and not enumerations, to specify these types (i.e., MIME types). Keith was pretty adamant on this issue and would have continued discussion, but Steve Z. and Scott suggested that discussion on the Printer MIB was not appropriate at an IPP WG meeting.
7. Server Timeout
The printer will abort a job after some server-configured inactivity timeout. If some documents had already been printed, the rest of the job is canceled. Larry Masinter questioned why IPP operations could not be "re-tried" if a failure occurred. Steve Zilles responded that there might be idempotency problems with operation retries. More discussion on the mailing list should be done.
8. Version Numbers
Given the number of HTTP WG members in the room, "a lively discussion" on capability negotiation and version numbers ensued. It is very likely that some combination of versioning, and capability negotiation will be required before gaining IESG acceptance.
9. Color
Will remain a boolean, "color-supported'. Leave it to the PDL to handle other color model and capabilities requirements. Some questions by the audience questioned the usefulness of a "boolean" to specify color capabilities. Keith Moore said that he would like to see the specification of color capabilities more fleshed out than just "yes, this device supports color". Larry Masinter also suggested that in order to curb the displeasure with such a "boolean" specification of color, that maybe the WG should remove this and just do a complete color capabilities model in a future version of IPP. He suggested that either IPP should do color (the right way), or not at all. After a brief rationale statement by Scott Isaacson and Steve Zilles for the boolean color-supported, both Larry and Keith seemed to understand why, but still were not crazy about the inclusion of color, without the WG "doing it right."
10. Date and Time
"Time-since-xxxx" attributes will be in "seconds" (and OPTIONAL). A MANDATORY "printer-up-time" will be added to the spec. and will essentially reflect the MIB-II "sysUpTime" object. Larry Masinter questioned why a printer "end-user" would care about how long the printer had been "up", since IPP 1.0 is basically targeted for end-users. He further questioned why the value was mandatory. The WG implied that since MIB-II sysUpTime was mandatory, that no undue burden should be placed on IPP implementations to support it.
11. Formatting Attributes
The WG will work on a proposal for "page-range" and "page-orientation" attributes.
12. Order of Jobs returned by "Get-Jobs"
OPEN.
13. Event Notification
The WG has an action item to specify event notifications. They should be machine-readable.
14. Media-ready vs. Media-supported
OPEN. Some implementation require this distinction. Especially server-based implementations of IPP. It was suggested that media-supported be dropped and only support for media-ready should be supported, since this would apply to all IPP configurations.
The I-D: <draft-ietf-ipp-dir-schema-01.txt> Internet Printing Protocol/1.0: Directory Schema was introduced by Scott Isaacson.
More work needs to be done to bring the current directory schema documents up to date with the current Model document. One of the members of the Service Location Protocol WG mentioned that they already have started working on a schema for Printing Class applications within their WG, and that input from the IPP WG is "very welcome" at this stage. Scott Isaacson stated that such cooperation should definitely take place.
II. Session on Wednesday, August 13 (minutes taken by Scott Isaacson)
Carl-Uno Manros opened the meeting and presented the agenda.
The I-D: <draft-ietf-ipp-rat-01.txt> Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol was introduced by Steve Zilles and then briefly discussed, limited to the protocol aspects, without any substantial comments.
The I-D: <draft-ietf-ipp-sec-01.txt> Internet Printing Protocol/1.0: Security was introduced by Carl-Uno Manros. The following comments and discussion followed:
1. Scope of security in IPP
What is in and what is out of IPP? How much can we rely on getting from the numerous IETF security projects and what do we have to do ourselves? Should not the HTTP group be responsible for security needed for HTTP? How is the use of TLS with HTTP specified? HTTP seem to ignore further standardization of Basic Authentication and are only progressing Digest Authentication.
2. Status of IETF security standards
There is an interest from IPP to use TLS for secure transmission, but the TLS standard is not yet finished. Can SSL be used instead?
3. Secure and insecure communication with the same IPP Printer
We should allow for the protocol to have some kind of negotiation mechanism. One suggestion was to always use TLS, allowing the client to be configured to run with TLS NULL, NULL, NULL.
It was also stated that the content of the current document will be divided up between the IPP Model & Semantics and Protocol Specification document in the next round of editing.
The I-D: <draft-ietf-ipp-protocol-01.txt> Internet Printing Protocol/1.0: Protocol Specification was introduced by Bob Herriot. The following comments and discussion followed:
1. Does IPP need to worry about the fact that some server implementations do not pass HTTP headers to the back end processes (CGI)?
No, this is an implementation problem.
2. Accept headers
Accept-charset is irrelevant
Accept-language is relevant
Accept-encoding probably (might be)
3. We need to make sure that the IPP mapping works with generic HTTP clients, HTTP origin servers, and HTTP proxy servers
4. Why POST over new method PRINT?
PRO POST
5. Why not use some other transport, such as SMTP?
IPP has been designed not to prevent this, however no interest in the WG to make such other mappings. Additional mappings could show a mapping of multiple operations in one MIME component, or could use Internet Fax extensions.
6. Content negotiation should be more symmetrical (client telling server, server telling client)
The I-D: <draft-ietf-ipp-lpd-ipp-map-01.txt> Mapping between LPD and IPP Protocols was introduced by Bob Herriot. The following points were discussed:
1. How does mapper support "host"?
IPP to LPD; set H to mapper host
LPD to IPP, ignore H
2. job-k-octets semantic change between IPP and LPD (which includes copy count?). Just do the mapping
3. Move to Job-ID vs. Job-URI
Needs to be resolved on the discussion list (see Model & Semantics discussion earlier).
4. Should IPP pick a format for queue status or make it dependent on each LPD implementation? Further discussion on the DL.
a. ignore the problem
b. pick a format
c. make it MUST or SHOULD
5. This mapping document is an INFORMATIONAL RFC, not an IMPLEMENTATION RFC
6. Should DVI, ditroff, or troff should be added as document-format types?
If we make them MIME types, then anyone can add them that wants them.
7. Open issue about mapping LPD to IPP error codes.
The chairs made clear that the intent of
the WG is to move current I-Ds to final call in September 1997.