NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 11-Mar-98
Steve Zilles <email@example.com>
Carl-Uno Manros <firstname.lastname@example.org>
Applications Area Director(s):
Keith Moore <email@example.com>
Harald Alvestrand <Harald.Alvestrand@maxware.no>
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 Interoperability 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.
· Requirements for an Internet Printing Protocol
· Internet Printing Protocol/1.0: Model and Semantics
· 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
· Requirements for IPP Notifications
· DHCP Option for Internet Printing Protocol Services
No Request For Comments
Minutes of the Internet Printing Protocol (ipp) Working Group
Reported by Tom Hastings
I. Requirements for Notification
II. Directory Features
III. Other Future Work
IV. Area Directors Questions about IPP
I. Requirements for Notification
Carl-Uno presented the requirements for IPP notification:
1. Notification Requester
2. Notification Recipient(s)
3. Notification Content (events, attributes)
4. Notification Formats (human, machine)
5. Notification Timeliness (email, immediate)
Scott Isaacson reported that there is an LDAP I-D in WG last call on dynamic attributes:
A requester can supply a "persistent search" on some dynamic attributes of an entry and get results whenever they change. Thus LDAP is providing a mechanism that could be used for notification. This approach scales, in that the LDAP server is centralized, so that each client that wanted to get notifications would register with the LDAP server once. Printers would indicate events to the LDAP server once for each event, no matter how many clients wanted results.
Scott also presented a summary of a survey of notification mechanisms that have been developed in other arenas:
· message queue (pull)
· publish/subscribe (push)
· Quality of Service (privacy, latency, authentication, authorization)
· Variants (durable, once, at least once, at most once)
· Industry (OMG, Java, SNMPv3, email, SMTP MDN/DSN
· Abstract Events:
- Printer (error, warning, report)
- Job (error, warning, report)
· Concrete Events:
· State Change (input tray < 50 sheets)
· Concentrate on abstract events
An attendee suggested that we consider Tool Talk
- has broadcast
- has event filtering
Jeff Case, SNMPv3 developer, was present and indicated that SNMPv3 needed the System Administrator to setup authorization for each subscriber.
Jeff Case and Keith Moore live near each other in Tennessee and will get together to discuss SNMPv3 capabilities and usage for notification. It would be good if a PWG member could attend their discussion as well.
II. Directory Schema
Scott Isaacson indicated that he and several other IPP folks worked with the SLP editor to update the printer scheme intended to cover an IPP printer and an LPD printer. The entries for each might look like:
The SLP STRINGL (L for literal) is identical to IPP keywords, i.e., no translation to user's natural language.
One SLP entry is needed for each printer and security combination. So even if an IPP Printer uses a single URI for both secure and regular, the SLP directory will need two entries.
In SLP, the concrete protocol is http and lpr, respectively, and the abstract protocol is ipp.
III. Future Work
Carl-Uno indicated that possible future work might include:
1) System Administrator functions
2) Extensions, such as dictionaries and per document attributes
3) MIME media types for each of the Printer MIB Interpreter Language families that do not currently have MIME media types.
4) Extensions for Host-to-Device usage
3.1 MIME media type feedback
IETF feedback indicated that we should ask vendor's whether they wanted to register their own Interpreter Language family, or wanted the PWG to do it on their behalf. Keith Moore indicated that there is no problem with the PWG registering something that a particular company owns, especially if it is in common usage but that company isn't registering the Interpreter Language family. On the other hand, if an Interpreter Language Family isn't being used any more, there is no point in registering it.
ACTION ITEM (Tom Hastings): prepare a straw man list of Printer MIB Interpreter Language family entries, indicating which already have MIME media types, which the PWG wishes to register, unless the vendor responds that they prefer to, and which the PWG has no interest in registering and will leave to the vendor to do as it pleases.
3.2 Host-to-device extensions
Keith Moore indicated that the IETF might be willing to have a host-to-device protocol on the IETF standards track. He'd like to hear more about it.
IV. Keith Moore's Questions and Feedback about IPP
Keith indicated that he is reading the IPP documents carefully. Because the document is long, it is taking a while. He and the IESG will have some responses in a few weeks. He has some questions that the group was glad to answer:
1) What kind of extensions can be added without effecting interoperation?
Answer: new values to existing attributes, new Job Template attributes, new Operation Attributes, and any Job Template attribute extension (if the requester omits or supplies the "ipp-attribute-fidelity" = 'false').
2) He questioned the Create-Job "ipp-attribute-fidelity" operation attribute being for all Job Template attributes at once. He thought that the *implementation code* would be simpler and more extensible if fidelity were specified per attribute.
Answer: We explained that we could compatibility add a Create-Job operation attribute that explicitly listed Job Template attributes that were compulsory (and/or one that listed Job Template attributes that were non-compulsory), since unknown operation attributes SHALL be ignored and returned in the response (with 'successful-ok-ignored-or-substituted-attributes' status code returned as a status). Only if ignoring an operation attribute extension would adversely affect new clients working with older servers, would we have to increment the major version number of the protocol. This was an illustration of how we could compatibly add attributes without impacting interoperability.
3) What job state should an IPP Printer return, if it sends jobs to a device or server that cannot be queried?
Answer: return the 'unknown' value for a query of the job's "job-state" attribute.
4) What were the IPP WG feelings about using the Post HTTP operation for all IPP operations?
Answer: The meeting attendees discussed the issue of using Post versus a new operation. Keith indicated that using a new operation would simplify administration of firewalls. On the other hand, there were HTTP experts present that said that the purpose of a Post operation was to update a data base. The IPP create operations certainly fit that description. However, the IPP query operations (Get-Job-Attributes, Get-Printer-Attributes, Get-Jobs), aren't updating a data base. There was no conclusion for or against using HTTP Post (or a mixture of Post and Get) or a new operation. As before, there are pros and cons.
IPP - Agenda
IPP Notifications - Requirements
IPP Generic Directory Schema
IPP - Typical Event/Notification Systems
go to list