NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99
Carl-Uno Manros <email@example.com>
Applications Area Director(s):
Keith Moore <firstname.lastname@example.org>
Patrik Faltstrom <email@example.com>
Applications Area Advisor:
Keith Moore <firstname.lastname@example.org>
To Subscribe: email@example.com
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:
Submit Internet Printing Protoco/1.0: Model and Semantics as an Internet-Draft.
Submit Internet Printing Protoco/1.0: Protocol as an Internet-Draft.
Submit Internet Printing Protocol: Requirements and Scenarios as an Internet-Draft.
Submit Internet Printing Protoco/1.0: Directory Schema as an Internet-Draft.
Review of specification in IETF meeting in Memphis, TN, USA
Produce At least 2 implemented prototypes
Submit other Internet-Drafts to IESG for consideration as Proposed Standards.
Submit Internet Printing Protocol: Requirements and Scenarios I-D to IESG for publication as an Informational RFC.
· Design Goals for an Internet Printing Protocol<!999999>
· Internet Printing Protocol/1.0: Model and Semantics<!999999>
· Mapping between LPD and IPP Protocols<!999999>
· Internet Printing Protocol/1.0: Encoding and Transport<!999999>
· Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol<!999999>
· Requirements for IPP Notifications<!999999>
· DHCP Option for Internet Printing Protocol Services<!999999>
· Internet Printing Protocol/1.0: Implementer's Guide<!999999>
· Internet Printing Protocol/1.1: Encoding and Transport<!999999>
· Internet Printing Protocol/1.1: Model and Semantics<!999999>
No Request For Comments
IPP WG Minutes - March 17, 1999
Carl-Uno Manros led the meeting for the Internet Printing Protocol (IPP) WG session. Around 30 people attended. Notes taken by Lee Farrell.
- IPP Status - Where do we stand?
- Highlights from the IPP bake-off
- Presentation of IPP 1.1 documents
- Highlight differences between 1.0 and 1.1
- Open discussion
The five draft documents that constitute IPP/1.0 have been accepted by the IESG as Experimental. These five documents are currently in the RFC Editor's queue for publication.· An IPP/1.0 Implementer's Guide document is currently out for IPP WG Last Call.· Two new drafts have been produced for IPP/1.1. They are currently out for IPP WG Last Call
Some objections have been raised on the mail list about finalizing IPP/1.1 "too quickly" before reasonable experience is gained on IPP/1.0. There is especially some concern with regard to over 20 issues that came up at the 2nd bake-off. Tension exists between delaying too long before the first standards track draft is issued and waiting for "sufficient stability" in experience with 1.0 version implementations before issuing a second specification.
Carl-Uno showed slides on the bake-off event. He explained the infrastructure set-up and services.
Highlights from the IPP bake-off
- 24 vendors (Carl-Uno provided list)
- 11 IPP clients
- 27 IPP printers
- 297 possible combinations
- 296 "basic print" feature successful after 3 days (one hold-out due to ROM implementation-couldn't modify code)
It was noted that "new faces" (i.e. never attended an IPP meeting) brought successful implementations. This suggests that the IPP/1.0 specification is clear enough for consistent interpretation.
Genoa is developing an IPP test suite that will be made available to the open market.
Q: How many vendors demonstrated the ability to handle multiple concurrent sessions?
A: It wasn't really one of the tests, but there was a wide spectrum of capability present-including a OS/390 mainframe machine that could handle 20 simultaneous HTTP/IPP connections.
Carl-Uno brought with him and showed a palm-sized IPP Print Server device implemented by i-data. It has 4 MB memory, and supports TCP/IP, HTTP, SNMP, SMTP, and SSL3, with a web server, plus four print protocols, including IPP.
Presentation of IPP 1.1 documents
IPP Protocol: Model and Semantics - draft-ietf-ipp-model-v11-00.txt
IPP Protocol: Encoding and Transport - draft-ietf-ipp-protocol-v11-00.txt
Important Differences between IPPv1.0 and v1.1
- Six new optional Operations
- Introduction of the ipp:// scheme
- TLS replaces SSL3 ("should" support TLS)
New Operations (all optional)
Carl-Uno provided background comments on the group's reluctance to adopt the IESG recommendation to implement ipp:// scheme. However, he points out that several people have shown that the scheme is relatively simple to implement.
It was noted that http:// is used on the wire. The Client translates before sending. Any URLs contained in the MIME message body are maintained as ipp://.
- Synonym for http://
- Has its own default port--#631
- Easy to map from/to http:// scheme
- If client uses http://, server responds with http://
- If client uses ipp://, server responds with ipp://
Use of TLS vs. SSL3
- SSL3 uses special scheme https:// and special port #443
- TLS uses ipp:// scheme and same port as IPP-#631
- For SSL3, the IPP client has to start up with https:// and later switch to http://
- For TLS, the IPP client starts up with http:// using the Upgrade header
Carl-Uno noted that he has heard rumors about "one little problem" with the Upgrade header, but the details were not clear. There was speculation that there might be a need for a registry of tokens and their meanings-to avoid collisions.
He also noted that there is not a lot of TLS code "lying around" for general use. He requested if anyone knows about SDK for TLS in Java-please notify him; the IPP WG is interested.
There was some discussion about handling both TLS and SSL3. There was some confusion about the correct interpretation regarding support of IPP/1.0 (and SSL3) as part of IPP/1.1. Carl-Uno suggested that if people have any suggestions for existing text on this issue, please send him comments. The Last Call period on the current document set will be extended.
Discussion about IPP-to-IFax BOF activity (now "TCN Docs"). One person reported that it is still not clear from the Area Director whether IPP is the accepted mechanism for the goals of this group. He explained that "due diligence" must be performed on clarifying the problem statement. There is a perception that the current approach might be "a solution looking for a problem."
Larry Masinter proposed that it's a small amount of work to merge both document sets (IPP/1.0 and IPP/1.1) into one. He suggests that we could pull the current experimental RFC documents from the Editor's queue, and include in the IPP/1.1 documents an informational description of IPP/1.0.
Larry pointed out that the preface to Experimental RFCs includes warnings that they are not standards-and should not be implemented.
Carl-Uno expressed his belief that many of the vendors that attended the Bake-off would be upset about "pulling the IPP/1.0 RFCs." He pointed out that there was strong desire to establish a document set to clearly define the IPP/1.0 version.
A popular compromise was suggested: do both. Include the "merge" of IPP/1.0 description within the IPP/1.1 document set-and obsolete the IPP/10 Experimental RFCs once the combined IPP/10 and 1.1 version is published. A benefit of this approach is that all relevant information would be available in a single document set-rather than having two document sets that are essentially the same.
Strong majority agreed that this was a good compromise approach. No one voiced any objections.
Larry and John Wenn volunteered to propose text modifications to achieve the merge. The proposed text will be issued for review by the IPP mailing list.
Issues to be addressed:
- How difficult is the actual modification of the documents?
- Is IPP/1.0 really a true subset of IPP/1.1?
- Can we (continue to) avoid the requirement that 1.1 Clients need to support 1.0 Servers?
- "How to be compatible with existing 'pre-standard' (i.e. IPP/1.0) implementations of IPP?"
Larry will analyze the effort to merge, and will issue a statement/proposal to the reflector as appropriate.
Shortly after the meeting, the chair extended the Last Call period for the IPP/1.1 documents and the IPP Implementer's Guide until April 30, 1999.