NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Steve Zilles <email@example.com>
Carl-Uno Manros <firstname.lastname@example.org>
Applications Area Director(s):
Keith Moore <email@example.com>
Harald Alvestrand <Harald.T.Alvestrand@uninett.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 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:
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
No Request For Comments
Minutes of the Internet Printing Protocol (IPP) WG
These minutes were taken by Steve Zilles.
Carl-Uno Manros began the meeting with an overview of the documents and the agenda for the meeting:
Review suggested resolution of existing issues on:
I. Model and Semantics document, presented by Scott Isaacson
II. Protocol Specification document, presented by Bob Herriot
In the recording below, issues and their suggested resolution are recorded as presented (sometimes with some expansion for clarity). In most cases, there was no discussion and the proposed solution was accepted as presented. If there was a discussion, this is recorded after the presented solution and if a different decision was made, this is recorded after the discussion as a decision.
I. Model Document Issues, Scott Isaacson
1. Major/Minor Versioning Rules
· Mandate common encoding across all versions
· All elements added in a new minor version can be ignored
· New major version indicates new support requirements
2. Allow empty attribute groups
· Be conservative in what is sent; send an empty group
· Be liberal in what is received; allow missing group on reception
3. ALL operations MAY return "Unsupported Attributes"
4. Define protocol value-size upper bounds for:
· URIs, charsets, natural languages, identifiers, ...
5. MUST-implement requirements for text and name strings; each string has a maximum length specification: some 63 octets, others 127 or 1023 octets.
Clarified validation checks for operation processing.
Non-secure implementation client supplies "requesting-user-name." If client does not supply a name, the printer will generate one (which need not be unique)
Is an authenticated mode required of all Printers?
Keith Moore would like to have this be true; without it the protocol will not be interoperable; that is, two implementations of the spec may not be able to find a common (authenticated) communication path
Keith asserts that the current rules require this, because use of an Internet accessible printer will require authentication; Keith believes that submitting it as documented will cause kick back from the IESG.
But, for interoperability, it is not the case that both client and server must do all the mechanisms as long on one or the other must do all; that means that requiring all clients to do the secure solution is enough to meet Keith's understanding of the rules
Jim Gettys: HTTP has an issue raised by Lotus to multiple servers, serving a single site; It appears that Digest Authentication (with a few tweaks based on an idea of Paul Leach) may meet this need (and that Microsoft and Netscape may be likely to implement Digest). Details on this discussion will play-out on the HTTP mailing list over the next few weeks.
Keith Moore: Whether Digest Authentication is enough is not an issue of whether it is secure enough, but whether this solution is sufficiently scalable (Jim G asserts that Paul Leach's solution may solve the scalability issue).
Keith points out that Diffie-Hillman is a (now) unencumbered mechanism for key exchange and should be relatively easy to implement.
It is noted that there are two different classes of interoperation over the Internet: (1) remote access to a private resource (such as the printer on my desk) versus (2) providing a service to all comers (such as a Kinko's service) over the Internet. Scalability is not an issue in the first case.
It was suggested that we identify the basic mode as "authenticated" mode (because Digest Authentication is already mandated for all HTTP/1.1 clients) and the full TLS based mode as secure mode.
Digest authentication is already mandated for all HTTP/1.1 clients IPP will mandate TLS for all clients
8. Removed "copies-collated" attribute
9. Identified sources for all text and name valued attributes:
allow any natural language for non-generated strings
name change to "generated-natural-languages-supported"
10. Keep "charset-supported"
11. Clarified semantics of "page-range" attribute
12. Support for Media attributes
· If supporting "media-default", then MANDATORY
· If supporting "media-supported", then MANDATORY
· If supporting "media-ready", then OPTIONAL
13. Added missing status codes
14. Asserted that IPP is already aligned with <draft-iesg-iana-considerations-01.txt>
15. Made "application/ipp" a "common usage" media type
Added "request ID" to allow matching of responses to corresponding request for protocols other than HTTP (e.g. SMTP) included all parameters, including the target object URI, within the application/ipp body.
· Allow for "non-secure", really "authenticated" servers
· If Privacy and/or Mutual Authentication is implemented, then it Shall be TLS
· For HTTP/1.1, mandate and allow what HTTP/1.1 mandates and allows
rename "non-secure" to "authenticated"
rename "secure" to "private and authenticated" (or something similar
WEBDAV has been asked to not allow basic authentication.
17. Provide input to the SVRLOC Printer Scheme I-D
18. Register all the SNMP printer languages as a (MIME) media types with cross-references to the SNMP enums.
19. Register "application/ipp" as a media type
Keith said the preferred method for handling the MIME type registration is to put the registration text (as per RFC2048) into the standards track RFC that uses/defines it. IANA should then automatically add it to the registry within a few days of the publication of the RFC.
20. Should we register new ports for IPP use
Keith Moore: a reason for a separate port number is to allow firewalls to be configured to allow or block the printing port.
But, Keith observes that firewall usage is typically to block all access except to particular servers and if HTTP is not allowed, then it is likely that printing would also not be allowed so this is not a big issue. Hence, Keith is neutral on registering a port for IPP.
IESG has made TLS remove creation of new ports for other protocols than HTTP. Ones that are already deployed were kept, but no new ones. Therefore, we should not have a separate new port for IPP over TLS.
Other than the port discussion, no new issues were raised.
II. Protocol Document Issues since August 1997, Bob Herriot
1. Attribute Group Tags
· Sender (of request or response) SHOULD send attribute group tag with no following attributes with the exception of the unsupported-attributes-tag which SHOULD be omitted.
· Recipient (of request or response) MUST accept as equivalent representations of an empty attribute group:
- attribute group tag with no following attributes
- expected but missing attribute tag
2. Identified a subset of the tag types (0-0xf) as being attribute group tags (some of which have not yet been assigned); these should be handled like attribute tags by any application/ipp recipient. The subset of tag types (0x10-oxff) are "value tags".
3. A recipient of a request or response MAY skip all attributes in an unknown group.
4. Printer-uri and job-uri
· MUST be on HTTP request line
· MUST also be in operation attributes
5. Job operations MUST be supported with both job-uri target and printer-uri target with job-id attribute
6. Create-job operation returns job-uri and job-id
7. Handling of localized text and names
Added two new data types:
1. localized text
2. localized name
Both of these are represented as an octet string with four fields:
1. length of natural language identification
2. natural language identification (per RFC
3. length of text/name
4. content of text/name
8. Request ID added to all requests and responses. Server returns received request-id in the response to the request that had the request-id. Client may match response with requests using the request-id; client is responsible for management of request id numbering space; in HTTP, the client can always use 0 as the request-id because HTTP guarantees responses in the order requests are made.
9. Renamed 'data-tag' to 'end-of-attributes' tag
10. Added new out-of-band values for
11. Definition of status codes and operations moved to model document
No new issues were raised at the meeting
III. Mapping between LPD to IPP, Bob Herriot, the document was updated as follows:
1. Added statement that this is informational and its intent is to help implements of gateways between IPP and LPD.
Now both job-id and job-uri are available. Allows job-id to be same as LPD job-id in relevant cases
3. job-originating-host was removed from IPP model; IPP-to-LPD must use some other means to supply the 'H'(host) parameter.
4. job-k-octets was clarified to count octets in one copy, not all copies; file size in lpq response does contain copies
5. Notification was removed from the IPP model; therefore support for LPD email notification is not possible
6. For document format, SNMP Printer MIB enums were replaced by (MIME) media types
· job-originating-user replaced by job-originating-user-name
· value is (explicitly) a human readable name
· value comes from underlying authentication mechanism and the attribute: requesting-user-name
No other issues were raised.
Since all issues presented had a proposed solution that was acceptable to the meeting; final copies of the documents, containing the proposed resolutions, will be prepared and circulated to the mailing list by the end of the week.
Assuming there are no significant comments received by December 18, the revised documents will be transmitted to the IESG for processing before the end of the year.
IV. IPP Summary Paragraph
The standards track documents on the IPP Model and Semantics and the IPP Protocol Specification and the informational documents on IPP Requirements, IPP Rationale and Mapping between IPP and LPD were discussed. WG final calls for these had either expired or were about to expire. Proposed solutions to all known problems were reviewed (and, where necessary, corrected) during the WG meeting. Unless some new issue arises, it is the intent that final documents that include the proposed solutions will be given to the IESG for final processing before the end of the year. With this action, we consider the WG's charter to be fulfilled and do not expect to meet at the next IETF meeting.
IPP Versioning Rules
go to list