A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Printing Protocol Working Group
of the IETF.
Title : Internet Printing Protocol/1.1: Model and Semantics
Author(s) : R. de Bry, T. Hastings, R. Herriot,
S. Isaacson, P. Powell
Filename : draft-ietf-ipp-model-v11-01.txt
Pages : 165
Date : 25-Feb-99
This document is one of a set of documents, which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This 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. A Job optionally supports
multiple documents. IPP 1.1 semantics allow end-users and operators to
query printer capabilities, submit print jobs, inquire about the status
of print jobs and printers, cancel, hold, release, and restart print
jobs. IPP 1.1 semantics allow operators to pause, resume, and purge
(jobs from) Printer objects. This document also addresses security,
internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [IPP-REQ]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [IPP-RAT]
Internet Printing Protocol/1.1: Model and Semantics (this document)
Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO]
Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG]
Mapping between LPD and IPP Protocols [IPP LPD]
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. Operator and administrator requirements are out
of scope for version 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
specifications, 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. 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. Finally, this
document defines rules for supporting IPP/1.0 clients.
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)
A URL for this Internet-Draft is:
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Content-Type: Multipart/Alternative; Boundary="OtherAccess"