RFC 2911 (rfc2911) - Page 2 of 224
Internet Printing Protocol/1
Alternative Format: Original Text Document
RFC 2911 IPP/1.1: Model and Semantics September 2000
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC 2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC 2568]
Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [RFC 2910]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [RFC 2569]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that
are satisfied in IPP/1.0. A few OPTIONAL operator operations have
been added to IPP/1.1.
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 specification documents, and gives background and rationale
for the IETF working group's major decisions.
The "Internet Printing Protocol/1.1: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1 [RFC 2616]. It defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines a new scheme named 'ipp'
for identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: 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.1 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.
Hastings, et al. Standards Track