RFC 2567 (rfc2567) - Page 2 of 43
Design Goals for an Internet Printing Protocol
Alternative Format: Original Text Document
RFC 2567 Internet Printing Design Goals April 1999
administrators. The design goals document calls out a subset of end
user requirements that are satisfied in IPP/1.0. Operator and
administrator requirements are out of scope for version 1.0.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol (this document)
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol [RFC 2568]
Internet Printing Protocol/1.0: Model and Semantics [RFC 2568]
Internet Printing Protocol/1.0: Encoding and Transport [RFC 2565]
Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]
Mapping between LPD and IPP Protocols [RFC 2569]
The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specifications, and gives background and rationale for the
IETF working group's major decisions.
The "Internet Printing Protocol/1.0: Model and Semantics" document
describes a simplified model consisting of abstract objects, their
attributes, and their operations that is independent of encoding and
transport. The model consists of a Printer and a Job object. The
Job optionally supports multiple documents. IPP 1.0 semantics allow
end-users and operators to query printer capabilities, submit print
jobs, inquire about the status of print jobs and printers, and cancel
print jobs. This document also addresses security,
internationalization, and directory issues.
The "Internet Printing Protocol/1.0: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1. It defines the encoding rules
for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document
gives insight and advice to implementers of IPP clients and IPP
objects. It is intended to help them understand IPP/1.0 and some of
the considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some
advice to implementers of gateways between IPP and LPD (Line Printer
Daemon) implementations.
Wright Experimental