INTERNET-DRAFT R. deBry
IBM Corporation
T. Hastings
Xerox Corporation
R. Herriot
Sun Microsystems
S. Isaacson
Novell, Inc.
P. Powell
San Diego State University
March 26, 1997
Internet Printing Protocol/1.0: Model and Semantics
draft-ietf-ipp-model-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to
use Internet-Drafts as reference material or to cite them
other than as "work in progress."
To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
West Coast).
Abstract
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 on the Internet. The
protocol is heavily influenced by the printing model
introduced in the Document Printing Application (ISO/IEC
10175 DPA) standard. Although DPA specifies the both end
user and administrative features, IPP version 1.0
(v1.0)is focused only on end user functionality.
deBry, Hastings, Herriot, Isaacson, Powell [Page 1]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
The full set of IPP documents includes:
Internet Printing Protocol: Requirements
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema
The requirements document takes a broad look at
distributed printing functionality, and it enumerates
real-life scenarios which 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. The
requirements document calls out a subset of end user
requirements which must be satisfied in the first version
of IPP. Operator and administrator requirements are out
of scope for v1.0. The model and semantics document
describes a simplified model with abstract objects, their
attributes, and their operations. The model introduces a
Printer object and a Job object. The Job object supports
multiple documents per job. The security document covers
potential threats and proposed counters to those threats.
The protocol specification is formal document which
incorporates the ideas in all the other documents into a
concrete mapping using clearly defined data
representations and transport protocol mappings that real
implementers can use to develop interoperable client and
server side components. Finally, the directory schema
document shows a generic schema for directory service
entries that represent instances of IPP Printers.
This document is the "Internet Printing Protocol/1.0:
Model and Semantics" document.
deBry, Hastings, Herriot, Isaacson, Powell [Page 2]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Table of Contents
1. Introduction............................................7
1.1 Conformance ..........................................8
1.1.1 Client Considerations .............................9
1.1.2 Server Considerations .............................9
2. Simplified Printing Model..............................10
3. IPP Objects............................................14
3.1 Printer .............................................14
3.2 Job .................................................17
3.3 Document Object .....................................18
3.4 Object Relationships ................................19
3.5 Object Attributes ...................................19
3.6 Object Identity .....................................21
4. IPP Operations.........................................22
4.1 Introduction ........................................22
4.2 Operation Semantics .................................23
4.2.1 Print Operation ..................................23
4.2.1.1 Print Request ................................24
4.2.1.2 Print Response ...............................25
4.2.2 Cancel Job Operation .............................25
4.2.2.1 Cancel-Job Request ...........................26
4.2.2.2 Cancel-Job Response ..........................26
4.2.3 Get Attributes Operation .........................26
4.2.3.1 Get-Attributes Request .......................27
4.2.3.2 Get-Attributes Response ......................27
4.2.4 Get Jobs Operation ...............................28
4.2.4.1 Get-Jobs Request .............................28
4.2.4.2 Get-Jobs Response ............................29
deBry, Hastings, Herriot, Isaacson, Powell [Page 3]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5. Object Attributes......................................30
5.1 Attribute Syntaxes ..................................30
5.1.1 Attribute Extensibility ..........................34
5.1.2 Relationship of Job and Printer Attributes .......36
5.1.3 Attribute Value Tags .............................38
5.1.3.1 Tagged Printer Attributes ....................38
5.1.3.2 Tagged Job Attributes ........................39
5.2 Job Template (job-template) Attributes ..............39
5.2.1 Job Sheet Attributes (Set by Client/End User) ....40
5.2.1.1 job-sheets (type4 keyword) ...................40
5.2.2 Job Notification (job-notification) Attributes (Set
by a Client/End User) ..................................41
5.2.2.1 notification-events (setOf type2 keyword) ....41
5.2.2.2 notification-addresses (setOf url) ...........42
5.2.3 Job Scheduling (job-scheduling) Attributes (Set by
Client/End User) .......................................43
5.2.3.1 job-priority (integer(1:100)) ................43
5.2.3.2 job-hold-until (type4 keyword) ...............44
5.2.4 Job Production (job-production) Attributes (Set by
Client/End User) .......................................45
5.2.4.1 multiple-documents-are (type1 keyword) .......47
5.2.4.2 best-effort (type2 keyword) ..................48
5.2.5 Document Production (document-production)
Attributes (Set by Client/End User) ....................49
5.2.5.1 medium (setOf type2 keyword) .................49
5.2.5.2 number-up (type3Enum) ........................57
5.2.5.3 sides (type2 keyword) ........................58
5.2.5.4 printer-resolution (type2 keyword) ...........59
5.2.5.5 print-quality (type2 keyword) ................60
5.2.5.6 copies (integer(1:2**31 - 1)) ................61
5.2.5.7 finishing (setOf type2 keyword) ..............61
5.2.5.8 compression (type2 keyword) ..................63
5.2.6 Document Format Attributes (Set by Client/End User)63
5.2.6.1 document-format (type2 keyword) ..............63
5.2.7 Job Size (job-size) Attributes (Set by Client and
Printer) ...............................................68
5.2.7.1 job-k-octets (integer(0:2**31 - 1)) ..........69
5.2.7.2 job-impressions (integer(0:2**31 - 1)) .......70
5.2.7.3 job-media-sheets (integer(0:2**31 - 1)) ......70
5.2.8 Number of Documents (Set by Printer) .............71
5.2.8.1 number-of-documents (integer(1:2**31 - 1)) ...71
5.3 Job Attributes Set by the Printer ...................71
5.3.1 Job Identification (job-identification) Attributes
(Set by the Printer) ...................................71
5.3.1.1 job-URL (url) ................................71
deBry, Hastings, Herriot, Isaacson, Powell [Page 4]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.3.2 Job Owner (job-owner) Attributes (Set by a Printer)72
5.3.2.1 job-originating-user (name) ..................72
5.3.2.2 job-originating-host (name) ..................72
5.3.2.3 user-locale (type3 keyword) ..................72
5.3.2.4 job-name (name) ..............................73
5.3.3 Job Status (job status) Attributes (Set by Printer)73
5.3.3.1 job-state (type1 keyword) ....................73
5.3.3.2 job-state-reasons (setOf type2 keyword) .....76
5.3.3.3 job-state-as-text (text) .....................78
5.3.3.4 output-device-assigned (url) .................78
5.3.3.5 submission-time (dateTime) ...................79
5.3.3.6 number-of-intervening-jobs (integer(0:2**31 -
1)) ..................................................79
5.3.3.7 job-message-from-operator (text) .............79
5.3.3.8 completion-time (dateTime) ...................79
5.4 Document Attributes .................................80
5.4.1 Document Data (document-data) Attributes (Set by a
Client/End User) .......................................80
5.4.1.1 document-name (name) .........................80
5.4.1.2 document-URL (url) ...........................80
5.4.1.3 document-content (octetString) ...............81
5.5 Printer Description (printer-description) Attributes81
5.5.1 Printer Identification (printer-identification
Attributes (Set by the Administrator) ..................81
5.5.1.1 printer-URL (url) ............................81
5.5.1.2 printer-name (name) ..........................81
5.5.2 Printer Description Attributes (Set by the
Administrator) .........................................82
5.5.2.1 printer-location (text) ......................82
5.5.2.2 printer-description (text) ...................83
5.5.2.3 printer-more-info-site (url) .................83
5.5.2.4 printer-driver-installer (url) ..............83
5.5.3 Printer Description Attributes (Set by the
Manufacturer) ..........................................83
5.5.3.1 printer-make-and-model (text) ................83
5.5.3.2 maximum-printer-speed (integerUnits) .........83
5.5.3.3 printer-more-info-manf (url) .................84
5.6 Printer Status (printer-status)Attributes ...........84
5.6.1 Printer Status Attributes (Set by the Printer) ...84
5.6.1.1 printer-state (type1 keywordEnum) ............84
5.6.1.2 printer-state-reasons (setOf type2 keyword) ..86
5.6.1.3 printer-is-accepting-jobs (boolean) ..........89
5.6.1.4 printer-state-as-text (text) .................89
5.6.1.5 queued-job-count (integer(0:2**31 - 1)) ......90
deBry, Hastings, Herriot, Isaacson, Powell [Page 5]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.6.2 Printer Status Attributes (Set by the
Administrator) .........................................90
5.6.2.1 printer-message-from-the-operator (text) .....90
5.7 Printer Behavior (printer-behavior) Attributes ......90
5.7.1 Printer Behavior Attributes (set by the
Administrator) .........................................90
5.7.1.1 printer-locale (locale) ......................90
5.7.1.2 fonts-substitutions (setOf setOf font) .......90
5.7.1.3 scheduling-algorithm (type3 keyword) .........91
5.7.1.4 printer-fonts (setOf font) ...................91
6. IANA Considerations....................................91
7. Security Considerations................................92
8. References.............................................92
9. Author's Address.......................................93
deBry, Hastings, Herriot, Isaacson, Powell [Page 6]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
1. Introduction
The Internet Printing Protocol (IPP) is an application
level protocol that can be used for distributed printing
on the Internet. The protocol is heavily influenced by
the printing model introduced in the Document Printing
Application (ISO/IEC 10175 DPA) standard. Although DPA
identifies both end user and administrative features, the
first version of IPP is focused only on the end user
functionality.
Section 2 is a comparison between the new IPP model and a
generic description of the various solutions and
architectures that exist in today's distributed printing
products. This section shows a high level mapping
between the complex set of inter-dependent distributed
printing components and the IPP model. This new IPP
model simplifies the back-end implementations by exposing
only the objects, attributes, and operations that are
essential for end user access and control of the print
subsystem. When future versions of IPP include operator
and administrator requirements, the model can be extended
to support the appropriate objects, attributes, and
operations.
Section 3 introduces the full semantics of the new
Printer, Job, and Document objects in the IPP model. It
covers how instances of these objects are identified,
named, and related to each other.
Section 4 covers the operations which are part of the IPP
model. These operations include: the Print, Cancel, Get
Attributes, and Get Jobs operations. The Print and Get
Jobs operations are performed by a Printer. The Get
Attributes operation is performed by either a Printer or
a Job. A Cancel Job operation is performed on a Job
object.
Section 5 describes the attributes, their syntaxes, and
semantics which are part of the IPP model. Each object's
attributes are described, and the attributes are grouped
into logical groups to help clarify their relationships
and meaning.
Sections 6-9 cover security, technical references, and
author contact information.
deBry, Hastings, Herriot, Isaacson, Powell [Page 7]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
1.1 Conformance
This specification uses the verbs: "shall", "should",
"may", and "need not" to specify conformance requirements
as follows:
- "shall": indicates an action that the subject of the
sentence must implement in order to claim conformance to
this specification
- "may": indicates an action that the subject of the
sentence does not have to implement in order to claim
conformance to this specification, in other words that
action is an implementation option
- "need not": indicates an action that the subject of
the sentence does not have to implement in order to claim
conformance to this specification. The verb "need not"
is used instead of "may not", since "may not" sounds like
a prohibition.
- "should": indicates an action that is recommended for
the subject of the sentence to implement, but is not
required, in order to claim conformance to this
specification.
A conforming implementation shall implement all
operations and objects defined in this document.
Attributes are conditionally mandatory. This means that
an implementation need not include an attribute if the
attribute controls a feature that the implementation does
not support. For example, a printer that can only print
on one side need not implement the "sides" attribute. A
printer that does not support any of the finishing
attribute values, need not implement the "finishing"
attribute. An implementation that does not allow for
non-ready supported values in addition to ready values,
need not implement a full set of possibly supported
values. A printer with only a single input tray with
only one media type in that tray need not implement the
"media" attribute.
Some of the attributes include values which are
extensible. The set of attributes themselves are also
extensible. Therefor, an IPP implementation (either
client or server) shall support these extensions. Some
implementations may choose to ignore private extensions,
deBry, Hastings, Herriot, Isaacson, Powell [Page 8]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
others my be able to support these values. On the client
side, this might mean displaying the values to the end
user via some extensible user interface mechanism. On
the server side, it might mean actually performing the
semantic action implied by the new value. In either
case, the operation shall not fail because either the
client or server does not understand extended values or
attributes.
IPP allows for variations on attributes using a mechanism
called "attribute tags" or "adornments" (see section
5.1.3). Clients can supply attributes with tags that
represent variations on the normal (unadorned) attribute
semantics. Servers can also respond with tagged
attribute information. Tags are most applicable and
useful in more sophisticated implementations. Therefor,
all adornment tags are optional for conforming
implementations. This allows for interoperability since
the behavior of implementations which can not support the
semantics of the adornment tags is consistent with the
behavior implied by the absence of all tags.
1.1.1 Client Considerations
IPP clients shall support all operations, objects, and
attributes as defined in this document. However, there
is no conformance requirements placed on the user
interfaces provided by IPP clients or their applications.
For example, one application might not allow an end user
to submit multiple documents per job, while another does.
One application might first query a Printer object in
order to supply a graphical user interface (GUI) dialogue
box with current supported and default values whereas a
different application might not. A conforming client may
choose to ignore any adornment tags it does not
understand.
1.1.2 Server Considerations
It is not required that a conforming server support all
(standard) values of all supported attributes. For
example, it is not required that a printer implement all
finishing methods indicated by the standard values. The
explicit requirement of the term "supported", with
respect to one of the attributes that deal with printer
functions or resources, is that the server shall
deBry, Hastings, Herriot, Isaacson, Powell [Page 9]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
recognize the attribute and those values that are
supported, and shall be able to respond to a query about
which values that printer does, in fact, support. A
conforming server shall ignore any adornment tags it does
not understand.
2. Simplified Printing Model
In order to a achieve its goal of realizing a workable
printing protocol for the Internet, IPP is based on a
simplified printing model which abstracts the many (often
complex) real world printing solutions. Many of these
include features, interfaces, and relationships that are
beyond the scope of IPP. IPP has to run in a distributed
computing environment where requesters of print services
(clients, applications, PC drivers, etc.) cooperate and
interact with print service providers. Although the
underlying configuration may be a complex n-tier
client/server system, an important simplifying step in
the IPP model is to expose only the key objects and
interfaces. The IPP model encapsulates the important
elements into three simple objects:
Printer (section 3.1)
Job (section 3.2)
Document (section 3.3)
Each of these objects has a set of operations associated
with it. These include:
Printer:
Print (section 4.2.1)
Get Attributes (section 4.2.3)
Get Jobs (section 4.2.4)
Job object
Get Attributes (section 4.2.3)
Cancel Job (section 4.2.2)
There are no operations defined for a Document object.
All document information is accessed through a Job object
and its operations.
It is important, however, to understand that in real
system implementations (which lie underneath the
abstracted IPP model), there are other components of a
print service which are not explicitly modeled in the IPP
model. These components allow for additional operator
deBry, Hastings, Herriot, Isaacson, Powell [Page 10]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
and administrator functionality. These components are
illustrated in the following figure:
+--------------+
| Application |
+------+-------+
|
o +..............+
\|/ | Spooler |
/ \ +..............+
End-User |
+-----------+ +-----+ +..............+ Existing
| Browser | | GUI | | Print Driver | Print
+-----+-----+ +--+--+ +..............+ Client
| | | |
| +---+------------+---+ +----+----+
N D S | | IPP Client |<--| Gateway |
O I E | +---------+----------+ +---------+
T R C | |
I E U |
F C R -------------- Transport --------
I T I
C O T | --+
A R Y +--------+--------+ |
T Y | IPP Server | |
I +--------+--------+ |
O | |
N +.................+ | IPP Printer
| Print Service | |
+.................+ |
| |
Output Device(s) |
--+
This figure shows that the abstraction of a Printer
object not only supports the functionality of the actual
output device but additionally supports (where
implementation configuration requires) the spooling,
scheduling, and multiple output device management
functions often associated with a print server.
In the IPP model, users take on the role of end users,
operators, or administrators based on authentication and
authorization mechanisms provided through the security
service(s). Printers are registered as entries in the
directory. End users find and select Printers based on
some sort of filtered and context based searching using
deBry, Hastings, Herriot, Isaacson, Powell [Page 11]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
the directory. The directory is used to store relatively
static information about the Printer. This allows end
users to search for and find Printers that match their
search criteria (name, context, printer capabilities,
etc.) All information about the Printer, both static and
dynamic information, can be accessed directly from the
Printer itself. The more dynamic information associated
with a Printer includes state, currently loaded and ready
media, number of jobs, errors, warnings, etc. Once an
end user selects a Printer, the end user interacts with
that Printer in order to determine status and
capabilities of the Printer and then submits jobs to the
Printer. When a job is submitted to the Printer, a Job
object is created. The end user then interacts with this
new Job to query its status and monitor the progress of
the job. End users may also cancel the Job. The end
user is able to register to receive certain events which
are then routed using the notification service(s).
It should be obvious, that not all existing or even
future print subsystems conform to this model directly.
The IPP model however, can be overlaid on top of any of
these products and architectures. How does this IPP model
fit on top of these systems? In order to answer that
question we must first consider a generic model that
allows us to describe the many different features and
components of these various systems.
Consider the figure above. Each distributed print
service product will include elements from the following
list:
End Users: End Users are humans who submit print jobs.
End users will issue IPP operation requests and receive
IPP operation responses through an end user interface.
GUI: A Graphical End User Interface developed
specifically for interacting with an IPP Client.
Browser: A World-Wide-Web Browser. IPP conforming systems
will support access to print functions using standard
Web Browsers.
Applications: Application software which produces printer
output and submits it for printing. Some applications
generate printer page description languages directly,
while others depend on operating system components, such
as a Print Driver, to do so.
deBry, Hastings, Herriot, Isaacson, Powell [Page 12]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Spooler: A system component which stores print jobs prior
to submitting them for printing. On the client side, a
spooler allows the application to run asynchronously from
the actual transmission and print operation. On the
server side, a spooler allows the server to receive and
store multiple jobs while printing. Spoolers are optional
components.
Print Driver: In some desktop operating systems, such as
Windows, Print Drivers are used by the operating system
to generate the actual PDL for a given device from an
internal, device independent presentation format. This
keeps the applications themselves from having to worry
about generating device specific data streams for each
possible output device. Print Drivers do not exist in all
environments.
IPP clients: IPP clients are computer network nodes with
which humans, though a GUI or a command line, or programs
interact in order to manipulate the distributed print
service. An IPP client uses the IPP protocol to invoke
IPP operations on another node. Each operation has
arguments and results associated with it. The IPP client
provides arguments which add information about the
operation requested, and receives results which describe
the status and outcome of the operation.
Gateway: Gateways provide a mechanism for supporting the
clients of existing print services, such as LPR. A
gateway transforms the protocol of an existing client
into IPP and vice-versa.
Transport: The transport system and protocol used to
carry IPP messages across the network. IPP assumes a
reliable transport protocol.
Notification Services: Notification services in the
network provide a means for asynchronously communicating
events such as completion of a print job back to an end-
user. These notification services are used by IPP but are
not included natively in the IPP protocol. Example would
be include e-mail, HTTP POSTs, or any other similar
service.
Directory Services: Directory services in the network
provide a means where IPP Printers can be advertised by
registering with the directory. Although not mandatory
in an IPP conforming system, the use of a directory
deBry, Hastings, Herriot, Isaacson, Powell [Page 13]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
service is suggested in order to provide printer location
services to end users. A generic directory schema for IPP
Printers is described in "Internet Printing Protocol/1.0:
Directory Schema".
Security: The IPP protocol itself does not contain any
unique security mechanisms, but rather it depends upon
existing security systems, such as Secure Sockets Layer
(SSL) to provide authentication, privacy and message
integrity.
IPP Server: An IPP Printer object is an abstraction of
some print service provider. An Printer, by definition,
supports the IPP protocol. The component that implements
the protocol on behalf of the Printer is called an IPP
Server. In real configurations, an IPP Server may be a
component of a print server or an output device.
Print Service: Print Services may be embedded in an
output device or implemented in a separate system which
is associated with an output device. The print service
receives requests from the IPP client, performs the
requested operation, and sends back results which
describe the status and outcome of the operation
requested. A print service normally provides queuing,
job management, and device management functions.
Output Devices: Output devices interpret the print data
and generate some form of output. In the case of a laser
printer, for example, this normally means rasterizing the
print data and putting the resulting marks on paper. An
output device may receive print data directly from a
client or through a Print server.
A specific implementation of a print service may not
include all of the elements described here, and the
physical packaging of elements is up to the
implementation. For example, an output device may include
a queue or a print server may include a rasterizer.
3. IPP Objects
3.1 Printer
A major component of the IPP model is the Printer object.
To the end user, the Printer object is an abstraction of
deBry, Hastings, Herriot, Isaacson, Powell [Page 14]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
not only the functionality typically associated with an
actual output device, but also the abstraction
additionally supports (where necessary) the spooling,
scheduling, and multiple output device management
functions often associated with a print server.
The capabilities and state of an IPP Printer are
described by its attributes. Printer attributes are
defined in the following categories:
Job Template Attributes (section 5.2)
Printer Description Attributes (section 5.5)
Printer Status Attributes (section 5.6)
Printer Behavior attributes (section 5.7)
Operations which can be invoked on a printer include:
Print (section 4.2.1)
Get Attributes (section 4.2.3)
Get Jobs (section 4.2.4)
An instance of a Printer object implements IPP. Using
the protocol, end users may query the attributes of the
Printer, submit jobs to the Printer, determine subsequent
states of submitted and queued jobs, and cancel their own
print jobs. The realization of a Printer object may take
on different forms for any given configuration of real
components. However, the details of the configuration of
real components must be transparent to the end user.
Since a Printer object is an abstraction of a generic
document output device, an IPP Printer object could be
used to represent any real or virtual device with
semantics consistent with the Printer object. For
example, an instance of a Printer object could be used
to front end a fax-out device, any kind of imager, or
even a CD writer.
Some examples of configurations supporting a Printer
object include:
1) An output device, with no spooling capabilities
2) An output device, with a built-in spooler
3) A print server supporting IPP with one or more
associated
output devices
3a) The associated output devices may or may not be
capable
deBry, Hastings, Herriot, Isaacson, Powell [Page 15]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
of spooling jobs
3b) The associated output devices may or may not
support IPP
See the following figures for some examples on how to
view Printer objects on top of other printing system
configurations. The embedded case represents
configurations 1 and 2. Configuration number 3 is
represented by the hosted and fan-out figures below.
deBry, Hastings, Herriot, Isaacson, Powell [Page 16]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Legend:
##### indicates a Printer object which is
either embedded in an output device or is
hosted in a server. A Printer object
may or may not queue/spool.
any indicates any network protocol or direct
connect, including IPP
embedded printer:
output device
+---------------+
O +--------+ | ########### |
/|\ | client |------------IPP------------># Printer # |
/ \ +--------+ | ########### |
+---------------+
hosted printer:
+---------------+
O +--------+ ########### | |
/|\ | client |--IPP--># Printer #-any->| output device |
/ \ +--------+ ########### | |
+---------------+
+---------------+
fan out: | |
+-->| output device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | client |-IPP-># Printer #-*
/ \ +--------+ ########### \ +---------------+
any\ | |
+-->| output device |
| |
+---------------+
3.2 Job
A Job object is used to model a job. A job can contain
one or more documents. The information required to
create a Job object is sent in a Print operation from the
end user via a client implementation to a Printer. The
deBry, Hastings, Herriot, Isaacson, Powell [Page 17]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Printer may perform some validation checks to verify that
the job may indeed be processed. For example, the Print
operation may request that the documents within the job
be printed duplex (on both sides of the media). However,
the Printer may not support such a feature. Once the
Printer validates the submitted information, a Job object
is created. The instance of the Job object is
initialized with information from the Print request along
with default information from the Printer. This document
defines rules which define which pieces of information
override other pieces of information and what to do in
the event of conflicts between what is possible and what
is requested.
Job attributes are broken up into the following groups:
Job Template Attributes optionally supplied by the
client/end user
Job Sheet Attributes (section 5.2.1)
Job Notification Attributes (section 5.2.2)
Job Scheduling Attributes (section 5.2.3)
Job Production Attributes (section 5.2.4)
Document Production Attributes (section 5.2.5)
Document Format Attributes (section 5.2.6)
Job Template Attributes set by Client and Printer
Job Size Attributes (section 5.2.7)
Job Template Attributes set by the Printer
Number of Documents Attribute (section 5.2.8)
Job Attributes set by the Printer
Job Identification Attributes (section 5.3.1)
Job Owner Attributes (section 5.3.2)
Job Status Attributes (section 5.3.3)
The following operations can be invoked on Jobs:
Cancel Job (section 4.2.2)
Get Attributes (section 4.2.3)
3.3 Document Object
Documents consist of printable data and attributes which
describe the data to be printed. In this version of the
protocol only the document format attribute may be
defined for individual documents.
Document attributes include:
Document Attributes (section 5.4)
deBry, Hastings, Herriot, Isaacson, Powell [Page 18]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Currently no operations are defined on documents.
3.4 Object Relationships
Instances of objects within the system have relationships
which must be maintained persistently along with the
persistent storage of the object attributes. A Printer
can represent one or more output devices. An output
device can be represented by one or more Printer objects.
A Printer can contain zero or more Job objects. A Job
object is contained in exactly one Printer object. A Job
object contains one or more Documents. If the Document
is simply a reference to some print data stream, the
reference may be used in multiple documents in the same
Job or even in different Jobs. If the Document is not
just a reference, but an actual stream of print data, it
shall only be contained in one Document.
3.5 Object Attributes
Each object type is defined by a set of attributes that
support and describe the realization of each instance of
an object. That is, a Printer object is defined as
specific set of attributes that are associated with each
instance of a Printer object. In the same manner, a Job
object is defined by defining the set of attributes that
will be associated with each instance of a Job object.
These attributes are defined in section 5 of this
document. Some attributes apply to only a Job object.
Some apply to only a Printer object.
In addition, there are some attributes that are shared
between both Printer objects and Job objects. These
attributes are defined in section 5.2. They are called
Job Template attributes. When one of these attributes is
part of a Job object, it specifies some end user job
processing instruction. It describes "what is wanted" by
the end user. When the attribute is part of a Printer
object, it specifies what the printer is capable of . It
describes "what is supported" by this instance of a
Printer. Also, as a Printer attribute, , the attribute
may have an optional default value which shall be used
for Jobs which do not supply an attribute value . This
default value describes "what will happen" if not
supplied in the by the end user in the Print Request.
deBry, Hastings, Herriot, Isaacson, Powell [Page 19]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
For example, one such Job Template attribute is the "job-
priority" attribute. When this attribute is part of a
Printer object, its value us a range of job priority
values. This range indicates what job priorities are
supported at this Printer. It may also have a default
value that determines what the job priority will be if
not supplied in the Print Request. When the "job-
priority" attribute is included with the Print Request,
it specifies the desired job priority for this job. If
the request does not include the job-priority attribute,
the Printer creates the Job object using the default
value from Printer attribute. If the Print Request does
supply a job priority value, the Printer must validate
the user supplied job priority; perhaps the end user is
requesting a job priority which is higher that what is
allowed by the Printer. If the value in the print request
is within the range of supported values, the request is
accepted and the Job object is created using the value
supplied by the end user. In this case, the Printer's
default value is not used. If the value supplied in the
request is outside the range of supported values, the
request is rejected.
Section 5.1 also introduces the notion of adornments on
attribute values in order to handle some nuances
associated with values of certain Job and Printer
attributes. These adornments are tags that are
associated with specific values in the attribute. For
example, in a Printer object, one of the attributes is
the medium attribute. A set of values in this attribute
implies that the Printer is capable of printing jobs on
those media types. However, there may be a distinction
between a supported value that is "ready" and another
that is "not-ready". This semantic information can be
passed between the Printer and interested clients by
using an "availability" tag which identifies each value
as either being ready or not ready (even though they are
all supported).
Two important attributes that need to be mentioned here
are the "multiple-documents-are" attribute and the "best-
effort" attribute.
The "multiple-documents-are attribute" is relevant only
if a job consists of two or more documents. It controls
finishing operations, job-sheet placement, and the order
of documents when the copies attribute is specified. The
end user uses this attribute in a Print Request to
deBry, Hastings, Herriot, Isaacson, Powell [Page 20]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
control whether multiple documents in the job are
intended to be finished or copied separately or as one
job. The values for this attribute are: "single-
document", "separate-documents-uncollated-copies", or
"separate-documents-collated-copies".
The "best-effort" attribute determines what to do if
there is a conflict between what a client requests and
what a Printer is capable of . Values for this attribute
are: "substitute-as-needed" and "do-not-substitute". If
the value for this attribute in a Print Request is
"substitute-as-needed" then the end user desires the job
be printed using substitutions by the Printer where
needed in order to resolve conflicts. If the value is
"do-not-substitute", then the end user desires that the
job should not be processed unless every attribute value
can be completely satisfied as specified. It is not
expected that this attribute is used much. Many clients
will submit a job with no attributes, and the Printer
will use default values. Other clients will submit a job
via a GUI which limits the attribute values to only those
which are supported. A value of "substitute-as-needed:
is useful in the GUI context only if an end user expects
the job to be moved to another Printer and prefers a sub-
optimal result to nothing at all. Also, an end user may
be printing a pre-formatted document where it is not
obvious that the client supplied attributes conflict with
what is in the print data itself or even if the printer
can satisfy the instructions already embedded in the pre-
formatted document. This "best-effort" attribute is most
useful in the case where an end user uses a command line
interface to blindly request attributes that may not be
supported.
3.6 Object Identity
All instances of Printer and Job objects have an
identifier attribute whose value is globally unique so
that they can persistently and unambiguously referenced.
The IPP model requires that these values be URLs as
defined by RFC 1738 and RFC 1808. In addition to an
identifier attribute, instances of Printer and Job
objects may have a name. An object name need not be
unique across all instances of all objects. The Printer
name is chosen and set by an administrator. The Job name
is created by the Printer using the name of the forst
document in the job. In all cases, the name only has
deBry, Hastings, Herriot, Isaacson, Powell [Page 21]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
local meaning, and is not constrained to be globally
unique.
To summarize, each instance of Printer and Job objects
will have two identifying attributes:
- xxx-URL: The globally unique locator for this object
instance
- xxx-name: The non-globally unique name for this object
instance
Document objects only have names, no identifiers. The
"document-name" attribute is used to store the name of
the Document. This name is just of interest within the
context of a Job. It need not be globally unique.
ISSUE: Do Documents need identifiers?
4. IPP Operations
4.1 Introduction
Printers and Jobs each have a set of operations
associated with it. End users, or programs invoke, these
operations through interactions with an IPP client. The
operations are:
For a Printer object:
Print (section 4.2.1)
Get Attributes (section 4.2.3)
Get Jobs (section 4.2.4)
For a Job object:
Cancel Job (section 4.2.2)
Get Attributes (section 4.2.3).
IPP objects are identified by URLs. When a client
communicates with a remote IPP object, it sends an
operation request to the URL for that object. Each
request carries along with it the parameters and data
required to perform the specified operation. Each
request requires a response from the object indicating
success or failure of the operation including response
data and/or error messages. Details of the IPP protocol
deBry, Hastings, Herriot, Isaacson, Powell [Page 22]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
are contained in "Internet Printing Protocol: Protocol
Specification."
It is assumed that URLs for IPP Printers are available to
end users or programs who wish to invoke Printer
operations. Although not mandatory, it is recommended
that Printers be registered in a directory service which
end users and programs can interrogate. "Internet
Printing Protocol: Directory Schema" defines the
attributes to be associated with an Printer entry in a
directory service.
ISSUE: We need to add "implementation notes." These are
helpful hints of how to map these abstract concepts to
real development efforts. Does it go here?
4.2 Operation Semantics
In this section, the four IPP operations are described in
terms of their contents and semantics.
4.2.1 Print Operation
When an end user desires to submit a print job, the
client sends a Print Request and receives a Print
Response. The information in a Print Request along with
any default information associated with the Printer is
sufficient to create a Job object. An instance of a Job
object contains all the information needed by the Printer
to print one or more documents as a print job.
When a Printer receives a Print Request, it either
accepts or rejects the request. The Printer accepts the
Print Request and creates a Job object if it is able to
accept each attribute in the request, and it rejects the
request and does not create a Job object if it rejects
any attribute in the request. There are five cases to
consider with respect to each attribute.
- The client supplies an attribute value and it is among
the values supported by the Printer: The job attribute is
accepted.
- The client supplies an attribute value but the
attribute is syntactically bad: The Printer rejects the
job.
deBry, Hastings, Herriot, Isaacson, Powell [Page 23]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
- The client supplies an attribute value and a) the
attribute value is not among the values supported by the
Printer, or b) the printer does not specify the
attribute: The job attribute is accepted only if the
best-effort attribute is set to substitute-as-needed
which allows the Printer to perform a best effort at
processing the job rather than rejecting the job. If
the job attribute is accepted, the Printer sets the value
of the attribute to a reasonable value, which may be the
Printer's default value if it is specified.
- The client does not supply a value, but the Printer
does: The attribute is accepted and when the Printer
creates a Job object, the Printer uses its default value.
If Printer is able to inspect the PDL and determine the
value of the embedded attribute, it sets the value of the
attribute to the embedded value and adorns it with the
embedded tag.
- Neither the client supplies an attribute value nor does
the Printer define a default value: The print request is
accepted, the Printer creates the Job object using
defaults as defined in this specification.
Issue: Can a Job object be created without some of the
attributes, then as the Printer processes the Job, there
is some default behavior as described either in this
document or a supplied on an implementation defined
basis. That is, if neither the client nor the Printer's
default supplies a value for a job attribute, then the
output device shall supply its own default value for that
job attribute, if necessary, in order to produce output.
4.2.1.1 Print Request
ISSUE: The client initially submits the request to a
Printer URL. If a client submits a job in fragments, the
initial submission returns a Job URL to which the client
submits subsequent fragments.
The following abstract data types are part of the Print
Request:
Job and A set of Job object and Document
Document attributes as defined in section 5.2.
Attributes This section may be empty. If so,
Printer defaults are used.
deBry, Hastings, Herriot, Isaacson, Powell [Page 24]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Document Document content is optional and shall
Contents not be included when a URL is provided
in the document-URL attribute which
points to the content.
The simplest Print Request consists of a document contents
and nothing else.
4.2.1.2 Print Response
The following abstract data types are part of the Print
Response:
Job- A URL Used for all other operations on
Identifier this Job.
Job Status All job attributes belonging to the job-
status group. The value of each
attribute shall be from a snapshot taken
sometime after the time the Printer
receives the print request. Since any
job affecting printer state information
(printer-state-reasons) is reflected in
the job-state and job-state-reasons, it
is sufficient to return only job status
attributes and no printer status
attributes.
Status status information including error
status
Message optional status message
The simplest response consists of the job identifier, Job
status, and operation status which is either an OK status or
Error status.
4.2.2 Cancel Job Operation
This operation allows a user to cancel one specific Print
Job any time after the print job has been established on
the Printer. Some pages may be printed before a job is
terminated if printing has already started when the
Cancel Job operation is received. Only the end user who
is also the job originator (job-originating-user Job
attribute) can cancel the job.
deBry, Hastings, Herriot, Isaacson, Powell [Page 25]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
4.2.2.1 Cancel-Job Request
The client submits the request to a Job URL.
The following abstract data types are part of the Cancel
Job Request:
Message Optional message to the operator.
4.2.2.2 Cancel-Job Response
The following information is part of the Cancel Job
Response:
Status status information including error
status
Message optional status message
4.2.3 Get Attributes Operation
This operation allows an end user to obtain information
from a Printer or Job object. The operation contains the
set of attributes names and/or attribute group names that
the requester is interested in. A corresponding
attribute list is returned in the response with the
appropriate attribute values filled in for each attribute
(explicitly named or implicitly included in an attribute
group) in the request.
If the request to a Printer does not supply any attribute
names, the Printer shall assume that the client is
implicitly requesting the default groups of "printer-
identification" and "printer-status". If the request to a
Job object does not supply any attribute names, the
Printer shall assume that the client is implicitly
requesting the default groups of "job-identification",
"job-owner", and "job-status".
deBry, Hastings, Herriot, Isaacson, Powell [Page 26]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
4.2.3.1 Get-Attributes Request
The client submits the request to a Job URL or Printer
URL.
The following abstract data types are part of the Get
Attributes Request:
Requested A set of attributes without values in
Attributes whose values the requester is
interested This is optional.
format This is used only when a this request
is sent to a Job and the end user is
interested in production attributes. In
that case, the client must the format
in the request since the default value
of the formats supported for the
Printer might be "auto-sense", and a
Printer's attributes or attribute
values may differ for each format that
it supports. This request value allows
a client to specify a particular
format.
There shall be a way to specify certain groups of
attributes, and it shall be possible to get more than one
group. The groups shall be organized in the same way as
this document and shall have the same names as the
sections heads of the groupings. Each section and
subsection contains the group name for the attributes in
that section or subsection.
For Printers and Job the special groups include:
- "none": no attributes of the specified object. NOTE:
none is primarily useful in Get Jobs, but can be
used as a ping with Get Attributes.
- "all": all attributes of the specified object.
4.2.3.2 Get-Attributes Response
The following abstract data types are part of the Get
Attributes Response:
Result The requested attributes of the object
Attributes with their current values, if the
requester supplied any Requested
deBry, Hastings, Herriot, Isaacson, Powell [Page 27]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Attributes
Status status information including error
status
Message optional status message
A Printer may choose, for security reasons, not to return
all attributes that a client requests. It may even return
none of the requested attributes. In such cases, the
status returned is the same as if the Printer had
returned all requested attributes. The client cannot tell
by such a response whether the requested attribute was
present or absent on the Printer.
4.2.4 Get Jobs Operation
This operation allows a client to retrieve Printer
attributes and a list of print jobs belonging to the
target Printer object. A list of Job attributes or
attribute groups that the client is interested in seeing
may be included in the request. If the request does not
supply any Printer attributes, the Printer shall assume
that the client is implicitly requesting the default
groups: "printer-identification" and "printer-status". If
the request does not specify any job attributes, the
Printer shall assume the default groups: "job-
identification", "job-status", "job-owner" and "job-
size". The Printer object will be returned first,
followed by the requested jobs in chronological order.
This order is explicitly defined to be: oldest to newest
with regard to completion time, either actual or
expected.
This operation is like Get Attributes, except that Get
Jobs can return attributes from more than one object.
4.2.4.1 Get-Jobs Request
The client submits the request to a Printer URL.
The following abstract data types are part of the Get
Jobs Request:
deBry, Hastings, Herriot, Isaacson, Powell [Page 28]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Job Owner This is the user-name. If the value is
non-null, then the requester wants only
those jobs whose job-originating-owner
is the same as the specified user-name.
If the value is null, then the requester
wants all jobs.
Job States A possibly empty set of job state
values. If the set is not empty,
then the requester wants only those jobs
whose job-state is the same as one of
the specified job state values, If the
set is empty , then the requester wants
all jobs that are pending or printing.
Requested A set of attribute names (without
Printer values) in whose values the requester is
Attributes interested from the specified Printer
Requested Job A set of attribute names (without
Attributes values) in whose values the requester is
interested from each of the jobs on the
specified Printer.
There shall be a way to specify certain groups of
attributes, and it shall be possible to get more than one
group. The groups are the same as for Get Attributes.
4.2.4.2 Get-Jobs Response
The following information is part of the Get Jobs
Response:
Result The result includes zero or more objects
Attributes each with zero or more attributes.
Status status information including error
status
Message optional status message
A Printer may choose, for security reasons, not to return
all attributes that a client requests. It may even return
none of the requested attributes. In such cases, the
status returned is the same as if the Printer had
returned all requested attributes. The client cannot tell
deBry, Hastings, Herriot, Isaacson, Powell [Page 29]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
by such a response whether the requested attribute was
present or absent on the Printer.
5. Object Attributes
This section describes the attributes with their
corresponding syntaxes and values that are part of the
IPP model. The sections below show the objects and their
associated attributes which are included within the scope
of this protocol. Many of these attributes are derived
from other relevant specifications:
ISO/IEC 10175 DPA (Final, June 1996)
RFC 1759 Printer MIB (Proposed Standard, May 1995)
Internet-Draft: Printer MIB (Draft Standard in
progress, December 1996)
Internet-Draft: Job Monitoring MIB (I-D in progress,
March 1997)
Each attribute is uniquely identified in this document
using a "keyword" in the section header describing that
attribute. A keyword is a sequence of characters (length
of 1 to 255) which consists of just letters, digits,
hyphen ("-"), and underscore ("_"). With these
restrictions, there will be a straight forward encoding
of these keywords onto real values in the protocol
specification. Not only are attributes uniquely
identified with keywords, some attributes take on a
syntax which is a set of keywords. This set of keywords
represents the domain of the attribute.
5.1 Attribute Syntaxes
The following table shows the basic syntax types that a
client and server shall be able to handle.
Table 1
Basic Type Description Comments
text a sequence of For free form human
characters: readable text
length: 0 to intended for human
4096 consumption.
deBry, Hastings, Herriot, Isaacson, Powell [Page 30]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Basic Type Description Comments
characters: any
name a sequence of
characters: some object via a
length: 1 to user-friendly
255 characters: string, such as a
For referencing
any Printer name, a
document name, a
user name, or a
host name. May
include the SPACE
character.
NOTE - The protocol
may need to provide
means to quote the
SPACE character if
the protocol uses
SPACE for other
purposes.
fileName a sequence of For referencing
characters: some file. The
length: 1 to limit is the same
1024 as POSIX and NT.
characters: any
keyword a sequence of For semantic
characters: identifiers of
length: 1 to entities in the
255 characters: abstract protocol
letters, (specified in this
digits, hyphen document). These
("-"), entities can be
underscore attribute names or
("_") values of
attributes, When a
keyword is used to
represent an
attribute (its
name), it must be
unique within the
full scope of IPP
objects and
attributes. When a
keyword is used to
deBry, Hastings, Herriot, Isaacson, Powell [Page 31]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Basic Type Description Comments
represent a value
of an attribute, it
must be unique just
within the scope of
that attribute.
That is, a keyword
can not be used for
two different
values of the same
attribute to mean
two different
semantic ideas.
However, the same
keyword can be used
across two or more
attributes,
representing
different semantic
ideas for each
attribute.
url a sequence of Universal Resource
characters: as Locator
defined in
rfc1738 and ISSUE: do we keep
rfc1808 URLs abstract here
too and not define
them in terms of
rfcs?
octetString a sequence of Used for opaque
octets data, such as the
document-content.
boolean two values of like an keywordSet,
true and false but there are only
two values. NOTE:
An application
might use a
checkbox for such a
value.
integer an integer each attribute
value that is specifies the range
in the range constraint
from -2**31 to
deBry, Hastings, Herriot, Isaacson, Powell [Page 32]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Basic Type Description Comments
2**31 - 1 explicitly.
dateTime a value that
holds the date time
and time to the
absolute date and
nearest second.
integerSeconds an integer with a relative time
implicit units
of seconds
integerPoints an integer with for measurment
implicit units
of computer
points, i.e.,
1/72 of an
inch.
integerUnits an integer with an integer value
explicit units expressed in units
ISSUE: we have two
types with implicit
units and one with
explicit units
where the units are
specific for one
attribute printer-
speed.
setOf X 0 or more for sets of values
values of type
X.
1setOf X 1 or more for sets of values
values of type
X.
setWithDefaultOf X 0 or more for sets of values
values of type where one is a
X and a default default value
value of type X
1setWithDefaultOf 1 or more for sets of values
deBry, Hastings, Herriot, Isaacson, Powell [Page 33]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Basic Type Description Comments
X values of type where one is a
X and a default default value
value of type X
withDefault X an explicit For values which
default value are not restricted
of type X. The but have a default.
set of values
is implicitly
unrestricted.
RangeWithDefaultOf a range of for a range of
X value of type X values, such as
with a default integers, where one
value of type X value is the
default.
OR the below syntax
type instead
integerRangeWithDef an integer for a range of
ault range with a integers where one
default integer value is the
value default.
5.1.1 Attribute Extensibility
This document uses prefixes to the keyword basic syntax
type in order to communicate extra information to the
reader through its name. This extra information need not
be represented in an implementation because it is
unimportant to a client or printer. The table below
describes the prefixes and their meaning
Basic Type Prefix Comments
keyword type1 someone must revise the IPP
standard to add a new name.
No private names are
allowed.
deBry, Hastings, Herriot, Isaacson, Powell [Page 34]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Basic Type Prefix Comments
keyword type2 implementers can, at any
time, add new values by
proposing them to the PWG
for registration (or an
IANA-appointed registry
advisor after the PWG is no
longer certified) where they
are reviewed for approval..
IANA keeps the registry.
Implementers can support
private (unregistered) with
a suitable distinguishing
prefix, such as -xxx- where
xxx is the company name
registered with IANA for use
in domain names.
keyword type3 implementers can add new
values by submitting a
registration request
directly to IANA, no PWG or
IANA-appointed registry
advisor review is required.
Implementers can support
private (un-registered)
names with a suitable
distinguishing prefix, such
as -xxx- where xxx is the
company name registered with
IANA for use in domain
names.
keyword type4 an installation defined name
that can be added to a local
system by an administrator.
Care must be taken by the
administrator to see that
keywords do not conflict
with other keywords defined
by the standard or as
defined by the implementing
product. There is no
registration or approval
procedure for type 4
keywords
deBry, Hastings, Herriot, Isaacson, Powell [Page 35]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.1.2 Relationship of Job and Printer Attributes
If a client can supply a Job attribute in a Print
Request, there is a corresponding Printer attribute with
the same name. The Printer attribute as a similar syntax
type, however, the Printer attribute must additionally
specify a set of supported values and an optional default
value. The default value is used when creating a new Job
object where the client has not supplied a value in the
Print Request. These attributes, which can be in both
Job and Printer objects, are called Job Template
attributes and are fully defined in section 5.2 "Job
Template Attributes". The table below shows the
relationships between the syntax types of Job attributes
and their corresponding Printer attributes. The syntax
type of the Printer object is "constructed" using Job
attribute type. For example, the table shows that if the
basic syntax type of a Job attribute is "text" then the
corresponding Printer attribute will be of type
"withDefault text". Or, if the syntax type of the Job
attribute is "integer", then the corresponding Printer
attribute will be of type "rangeWithDefault of integer".
The essence of what is shown in the table below is
whether a context (Job attribute or Printer attribute)
allows a single value or multiple values.
Name of Job Printer Attribute
syntax type Attribute Syntax
Syntax
text text withDefault text
name name withDefault name
keyword keyword setWithDefaultOf
keyword
or
or
setOf
keyword 1setWithDefaultOf
keyword
or
deBry, Hastings, Herriot, Isaacson, Powell [Page 36]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Name of Job Printer Attribute
syntax type Attribute Syntax
Syntax
1setOfkeywo
rd
boolean boolean setWithDefaultOf
boolean
url url withDefault url
integer integer rangeWithDefaultOf
integer
integerUnits integerUnit rangeWithDefaultOf
s integer, setOf Units
dateTime dateTime not needed because
there are no job
production attributes
that a client can
supply.
integerSecon integerSeco rangeWithDefaultOf
ds nds integerSeconds
NOTE: if have
integerUnits and no
integerSeconds, we can
replace
rangeWithDefaultOf by
integerRangeWithDefaul
t.
setOf X setOf X setWithDefaultOf X
The Printer and the client shall be knowledgeable about
each of the above syntax forms and know how the handle
the values in a Job attribute and a Printer attribute.
deBry, Hastings, Herriot, Isaacson, Powell [Page 37]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.1.3 Attribute Value Tags
In order to handle some nuances associated with Job and
Printer attribute values, attribute values can have tags
associated with them. The following sections describe
these tags. All tags are optional. Fully conforming
implementations need not support them.
5.1.3.1 Tagged Printer Attributes
Job Template attribute values in a Printer can have extra
tags associated with them:
- Availability: Some supported attributes shall have an
availability value associated with each value. A client
may choose to display values only with certain values of
availability. Standard values are: "ready" and "not-
ready". If an attribute value does not have this tag,
it is by default "ready". "not-ready" means that the
Printer can accept the job, but the Printer cannot
complete the job without some external intervention to
make the value ready.
ISSUE: Should the following availability tags be added
which help to more clearly specify some subtle meanings?
These include "virtually-ready" (ready enough for the
Printer to schedule the job since it the value is
intended to always be ready, media in manual-feed trays
would have this value), "on-order" (not-ready and cannot
be made ready soon, but something is happening), or
"special-order" (not-ready and cannot be made ready soon,
nothing is happening).
- Embedded-only: Some supported production attributes
have an "embedded-only" tag associated with an attribute
to indicate that the Printer supported this attribute
when it is embedded in the document data, but it does not
support it as an explicit attribute. The attributes that
this tag is attached to varies according to the format
specified in the Get Attributes operation.
- Default Value: Supported attributes can have a default
tag associated with the value that is default. If
multiple values are tagged with a default value, a client
shall use the first value that is tagged with default. If
no values are tagged, then it assumes the first value in
the supported list is the default value.
deBry, Hastings, Herriot, Isaacson, Powell [Page 38]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
- Scheduling: If a printer uses this value for
scheduling, then it associates this tag to indicate that
it would like the attribute set when the job is
submitted. The attribute can come back with or without
the embedded tag. If an attribute does not have this tag,
then the Printer will not use this attribute for
scheduling.
NOTE: the mostly likely attribute that a Printer would
attach this adornment to is the media attribute.
5.1.3.2 Tagged Job Attributes
Job attribute values set by a client and defined in
section 5.2 "Job Template Attributes" can have the
following extra tags associated with them:
- Embedded: If an attribute has this tag, then the
attribute value(s) are embedded in the document. The
printer can use this information for scheduling, but it
shall not use it to modify the document. This attribute
cannot be associated with individual attribute values.
- Default: If a attribute value has this tag, then the
Printer shall ignore the Job attribute, if any, and shall
use the Printer's default value for the attribute.
Issue: Does the following imply too much about using
"fan-in" for multiple default sets for a given output
device? Note: it is the duty of an administrator to
create a reasonable number of Printers feeding into each
output device to handle user's expected defaults. For
example, a Windows client will send a PostScript document
with no attributes. For production attributes, a
Printer's defaults must be "as-is". But other clients
may want to force PostScript files to print two-sided.
For those clients, there must be another printer whose
sides default is "2-sided-long-edge".
5.2 Job Template (job-template) Attributes
The following attributes can exist in both Jobs and
Printers. When such an attribute is in a Job object, it
identifies some desired behavior on this Job by the
Printer. When it is in a Printer object, it constrains
the values that the corresponding Job attribute can have
deBry, Hastings, Herriot, Isaacson, Powell [Page 39]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
and it specifies a default value as well. The set of
values in the Printer object are called the "supported
values".
These attributes form the attribute group called "job-
template".
The attributes are described below. The part in
parenthesis after each attribute name is the name of the
syntax as listed in Table 1 in section 5.1.
A client can specify any of the attributes in this group
in a Print Request. If a client GUI wishes to present a
user with a list of values to choose from, then the
client program should perform the Get Attributes
operation to a Printer URL using the group job-template
in order to get the complete list of attributes that a
client can specify. Each attribute returned with the job-
template group shall contain a list of supported values
for the attribute and the Printer's default value.
5.2.1 Job Sheet Attributes (Set by Client/End User)
The client shall specify these attributes to control the
printing of job sheets.
There is no group name for these attributes since there
is only one attribute in the group.
The client may also specify job sheet attributes in: Get-
Attributes and Get-Jobs.
5.2.1.1 job-sheets (type4 keyword)
5.2.1.1.1 As a Job Attribute
This job attribute determines what type of job-sheets
(banner pages) the Printer shall print with the job.
The standard values are: "none", and "default-sheet".
The value "none" means that end user desires no job sheet
be printed. The value "default-sheet" means that the end
user desires a site specific default sheet defined by and
administrator be printed.
deBry, Hastings, Herriot, Isaacson, Powell [Page 40]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.2.1.1.2 As a Printer Attribute
This printer attribute identifies the default job-sheet.
It also identifies the job-sheet values supported by this
printer, and the state of readiness for each job-sheet.
To allow no job sheets, the system administrator shall
include the value none as a value for the supported
values. If the administrator's policy is not to support
none, the Printer shall use the default-sheet value if
the client supplies the none value but also indicates
(through the best-effort attribute) that Printer could
substitute values as needed in order to process the job.
5.2.2 Job Notification (job-notification) Attributes (Set by
a Client/End User)
The client shall specify these attributes to indicate
events that the client is interested in, along with the
notification address and method for performing the
notification.
These attributes form the attribute group called "job-
notification".
The client may also specify notification attributes in:
Get-Attributes and Get-Jobs.
5.2.2.1 notification-events (setOf type2 keyword)
5.2.2.1.1 As a Job Attribute
This job attribute specifies the events about which the
end user want to be notified.
Standard values within the set are: job-completion, job-
canceled, job-problems and printer-problems.
If this attribute contains the empty set, the Printer
shall not notify. This value is useful if an
administrator has set up a notification Printer default
but the end user does not want notification.
deBry, Hastings, Herriot, Isaacson, Powell [Page 41]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
If this attribute contains the value: job-completion, the
Printer shall notify the client when the job containing
this attribute completes with or without errors.
If this attribute contains the value: job-canceled, the
Printer shall notify the client when the job containing
this attribute is canceled by the end-user or by the
operator, or aborts before completion.
If this attribute contains the value: job-problems, the
Printer shall notify the client when this job has a
problem while this job is printing. Problems include:
paper jam and out-of-paper.
If this attribute contains the value: printer-problems,
the Printer shall notify the client when any job,
including this job, is affected by a Printer problem (the
printer has moved to the stopped state and there is a
reason in the printer-state-reasons attribute) while this
job is waiting to print or printing. Problems include:
paper jam and out-of-paper.
5.2.2.1.2 As a Printer Attribute
This printer attribute indicates the default value. It
also indicates the values of the job and printer
notification-events attribute supported by this Printer
and the states of readiness for each value.
This document does not specify how or whether an
administrator can configure the information that a
Printer sends with an event when a Printer notifies a
user about the occurrence of an event.
If this attribute is unspecified, then the Printer does
not support notification. If this attribute is not
contained in an instance of a Printer and the client
supplies the attribute in the Print Request, the
attribute in the Print Request is ignored.
5.2.2.2 notification-addresses (setOf url)
This address specifies both the address and mechanism for
delivery of notification events to the client.
deBry, Hastings, Herriot, Isaacson, Powell [Page 42]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
The Printer shall use this attribute as the address for
sending messages to a job submitter when an event occurs
that the end user has registered an interest in.
If the URL has a "mailto:" scheme, then email is used and
the rest of the URL is used as the email address. If the
URL has a "http:" scheme, then an HTTP method is used to
add HTML formatted events to the end of the specified
HTML file.
5.2.2.2.1 As a Job Attribute
This job attribute specifies the method and addresses to
which the Printer should send messages when events
specified by the notification-events attribute occur.
5.2.2.2.2 As a Printer Attribute
This Printer attribute's syntax type is "setOf urlScheme"
so that an interested client shall know which URL schemes
can be include in the notification-addresses attribute in
the Print Request.
5.2.3 Job Scheduling (job-scheduling) Attributes (Set by
Client/End User)
The client shall specify these attributes to provide the
Printer with information for the scheduling a print-job.
These attributes form the attribute group called "job-
scheduling".
The client may also specify these attributes in: Get-
Attributes and Get-Jobs.
5.2.3.1 job-priority (integer(1:100))
5.2.3.1.1 As a Job Attribute
This job attribute specifies a priority for scheduling
the print-job. Printers that employ a priority-based
scheduling algorithm use this attribute.
deBry, Hastings, Herriot, Isaacson, Powell [Page 43]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
A higher value specifies a higher priority. The value 1
is defined to indicate the lowest possible priority (a
job which a priority-based scheduling algorithm shall
pass over in favor of higher priority jobs). The value
100 is defined to indicate the highest possible priority.
Priority is expected to be evenly or "normally"
distributed across this range. Among those jobs that are
ready to print, a Printer shall print all jobs with a
priority value of n before printing those with a priority
value of n-1 for all n. The mapping of vendor-defined
priority over this range is implementation-specific.
5.2.3.1.2 As a Printer Attribute
The printer attribute specifies the default priority. It
also specifies the supported range available to end-
users. When setting up this attribute, an administrator
might identify only a subset of the full range which is
the range that the end user is authorized to use. There
might be higher or lower priorities (outside the range
defined for end users) available to operators or other
privileged users.
If this attribute is not contained in an instance of a
Printer and the client supplies the attribute in the
Print Request, the attribute in the Print Request is
ignored.
5.2.3.2 job-hold-until (type4 keyword)
5.2.3.2.1 As a Job Attribute
This job attribute specifies the named time period during
which the Job print job shall become a candidate for
printing.
Standard values for named time periods are: "no-hold",
"evening", "night", "weekend", "second-shift", "third-
shift". An administrator shall associate allowable print
times with a named time period. An administrator is
encouraged to pick names that suggest the type of time
period.
If the value of this attribute specifies a time period
that is in the future, the Printer shall add the job-
deBry, Hastings, Herriot, Isaacson, Powell [Page 44]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
hold-until-specified value to the job's job-state-reasons
attribute and shall not schedule the print-job for
printing until the specified time-period arrives. When
the specified time period arrives, the Printer shall
remove the job-hold-until-specified value from the job's
job-state-reason attribute and, if no other reasons
remain, shall consider the job as a candidate for
processing.
If this job attribute value is the named value "no-hold",
or the time period has already started , the job shall be
a candidate for processing immediately.
5.2.3.2.2 As a Printer Attribute
This printer attribute indicates the default value. It
also indicates the values of the attribute supported by
this printer.
If this attribute is not contained in an instance of a
Printer and the client supplies the attribute in the
Print Request, the attribute in the Print Request is
ignored.
5.2.4 Job Production (job-production) Attributes (Set by
Client/End User)
The client shall specify these attributes to affect the
rendering, production and finishing of the documents in
the job. Similar types of instructions may also be
contained in the document to be printed.
These attributes form the attribute group called "job-
production".
If there is a conflict between the value of one of these
attributes, and a corresponding instruction in the
document (either implicit or explicit), the value of the
attribute shall take precedence over the document
instruction.
A job production attribute provides a client with a way
to request some feature at print time that may not have
been embedded within the document data when the document
was created. A job production attribute also provides a
client with a way to override a feature at print time
deBry, Hastings, Herriot, Isaacson, Powell [Page 45]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
that was embedded within the document data when the
document was created.
Note: until companies that supply interpreters for PDL's,
such as PostScript and PCL allow a way to specify
overrides for internal job production instructions, a
Printer may not be able to implement these attributes for
some PDL's.
A job production attribute tells a Printer what features
the job needs. A program that translates document data to
a Printer's PDL, and/or merges production attributes into
the document data should add job production attributes
to a job, using the "embedded" tag. Such a program may
execute at a number of different points in time:
1. The program produces a final form document and
stores these resource attributes in a file before the
end-user submits the print job.
2. The program produces a final form document data
stream when the end-user specifies "Print" to the
application program (e.g., Windows GDI driver).
3. The program running in the context of the Printer or
server translates a revisable or final form document
into a PDL that the output device understands.
For example, a job production attribute medium with the
value of "letter" requests that a job be printed on
letter paper, and gives information about what resources
the job needs. For example, a job production attribute
media with the values of "letter" and "ledger" and the
tag "embedded" tell a Printer that the job needs letter
and ledger paper, but gives no information about which
pages use each medium_ that information is embedded in
the document.
A Printer may use these attributes to validate and
schedule the print-job without interpreting the contents
of the document. This provides the opportunity for a
Printer to support a broad set of document formats yet
still support fast efficient scheduling and validation of
each job.
If any of these attributes is unspecified, the Printer
shall assume that the all resources required by the
document of the type specified by the missing attributes
deBry, Hastings, Herriot, Isaacson, Powell [Page 46]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
are ready, i.e., are available to the Printer and/or
output device without human intervention.
The client may specify these attributes in: Get-
Attributes and Get-Jobs.
The client may also specify job production-instruction
attributes in: Get-Attributes and Get-Jobs. For all the
attributes in this section, the default behavior if the
Printer attribute is unspecified is that the document is
printed with the output-device defaults, possibly
overridden by whatever is in the document data, if
anything.
Each attribute which is of type keyword in this section
also has a special value: "ignore" which is useful for a
file type, such as PostScript, which the Printer may not
allow changes to.
5.2.4.1 multiple-documents-are (type1 keyword)
5.2.4.1.1 As a Job Attribute
This job attribute is relevant only if a job consists of
two or more documents. It controls finishing operations,
job-sheet placement, and the order of documents when the
copies attribute exceeds 1.
This attribute can have one of three values: single-
document, separate-documents-uncollated-copies, separate-
documents-collated-copies.
If the files for the job are a and b and this attribute's
value is single-document , then files a and b are treated
as a single document for finishing operations. Also,
there will be no slip sheets between files a and b. If
more than one copy is made, the ordering must be a, b, a,
b, ....
If the files for the job are a and b and this attribute's
value is separate-documents-uncollated-copies, or
separate-documents-collated-copies or unspecified, then
each file is treated as a single document for finishing
operations. Also, a client may specify that a slip sheet
deBry, Hastings, Herriot, Isaacson, Powell [Page 47]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
be between files a and b. If more than one copy is made,
and the attribute's value is separate-documents-
uncollated-copies or unspecified, the ordering is a, a,
b, b, .... If more than one copy is made, and the
attribute's value is separate-documents-collated-copies,
the ordering is a, b, a, b, ....
5.2.4.1.2 As a Printer Attribute
This printer attribute specifies the default value and
the supported values.
5.2.4.2 best-effort (type2 keyword)
This attribute determines what to do if there is a
conflict between what a client requests and what a
Printer is capable of . Values for this attribute are:
"substitute-as-needed" and "do-not-substitute".
5.2.4.2.1 As a Job Attribute
This job attribute specifies the Printer should do if the
Printer can not support all other attribute values in
other Job attributes. If the value is "substitute-as-
needed" then the end user desires the job to be printed
using substitutions by the Printer where needed in order
to resolve conflicts. If the value is do-not-substitute
then the end user desires that the job should not be
processes unless every attribute value can be completely
satisfied. If the client does not supply a value for
this attribute in a print request, the Printer shall
assume that the value is "do-not-substitute."
Note: that best-effort is unlikely to be used much. Many
clients will submit a job with no attributes, and the
Printer will use default values. Other clients will
submit a job via a GUI which limits the attribute values
to those which are supported. Best-effort is useful in
the GUI context only if a user expects the job to be
moved to another printer and prefers a sub-optimal result
to nothing at all. Best-effort is most useful in the case
where an end-user uses a command line interface to
request attributes that may not be supported.
deBry, Hastings, Herriot, Isaacson, Powell [Page 48]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.2.4.2.2 As a Printer Attribute
This printer attribute specifies supported and default
behavior of the Printer if there is a conflict between
Job attributes and Printer supported attributes, If the
value is "substitute" then Printer is capable of doing
some sort of best effort when there is a conflict, If
the value is do-not-substitute then the Printer will
reject all print requests that can not be completely
satisfied. If the Printer object does not instantiate
this attribute, the client shall assume that the value is
do-not-subtitute.
5.2.5 Document Production (document-production) Attributes
(Set by Client/End User)
These attributes are similar to Job Production Attributes
except that they may also be associated with a document
and override the same attribute associated with the job.
These attributes form the attribute group called
"document-production".
5.2.5.1 medium (setOf type2 keyword)
5.2.5.1.1 As a Job Attribute
This job attribute identifies the medium that the Printer
shall use for all pages of the document regardless of
what media are specified within the document.
The values for medium include medium-names, medium-sizes,
input-trays and electronic forms so that one attribute
specifies the media.
If a printer allows a client to specify a medium-name as
the value of this attribute, such a medium-name
implicitly selects an input-tray that contains the
specified medium.
If a printer allows a client to specify a medium-size as
the value of this attribute, such a medium-size
implicitly selects a medium-name which in turn implicitly
deBry, Hastings, Herriot, Isaacson, Powell [Page 49]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
selects an input-tray that contains the medium with the
specified size. If a printer contains two or more medium-
names with the same medium-size, then a printer shall not
include that medium-size in the list of supported values
for this attribute and the printer shall reject jobs that
request such a medium-size.
If a printer allows a client to specify an input-tray as
the value of this attribute, such an input-tray
implicitly selects the medium that is in that input-tray
at the time the job prints. This case includes manual-
freed input-trays.
If a printer allows a client to specify an electronic
form as the value of this attribute, such an electronic
form implicitly selects a medium-name which in turn
implicitly selects an input-tray that contains the medium
specified by the electronic form. The electronic form
also implicitly selects an image that the Printer shall
merge with the data from the document as its prints each
page. When this attribute appears as a job attribute with
the embedded tag, it may contain more than one value and
it shall indicate all media required by the document.
5.2.5.1.2 As a Printer Attribute
This printer attribute identifies the default value. It
also identifies the media, media-sizes, input trays, and
electronic forms supported by this printer, and indicates
the state of availability for each medium resource.
Standard values are defined(taken from ISO DPA and the
Printer MIB):
default The default medium for the
output device
iso-a4-white Specifies the ISO A4 white
medium
iso-a4-colored Specifies the ISO A4 coloured
medium
iso-a4- Specifies the ISO A4
transparent transparent medium
iso-a3-white Specifies the ISO A3 white
medium
iso-a3-colored Specifies the ISO A3 coloured
medium
deBry, Hastings, Herriot, Isaacson, Powell [Page 50]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
iso-a5-white Specifies the ISO A5 white
medium
iso-a5-colored Specifies the ISO A5 coloured
medium
iso-b4-white Specifies the ISO B4 white
medium
iso-b4-colored Specifies the ISO B4 coloured
medium
iso-b5-white Specifies the ISO B5 white
medium
iso-b5-colored Specifies the ISO B5 coloured
medium
jis-b4-white Specifies the JIS B4 white
medium
jis-b4-colored Specifies the JIS B4 coloured
medium
jis-b5-white Specifies the JIS B5 white
medium
jis-b5-colored Specifies the JIS B5 coloured
medium
The following standard values are defined for North
American media:
na-letter-white Specifies the North American
letter white medium
na-letter- Specifies the North American
colored letter coloured medium
na-letter- Specifies the North American
transparent letter transparent medium
na-legal-white Specifies the North American
legal white medium
na-legal-colored Specifies the North American
legal coloured medium
The following standard values are defined for envelopes:
iso-b4-envelope Specifies the ISO B4 envelope
medium
iso-b5-envelope Specifies the ISO B5 envelope
medium
iso-c3-envelope Specifies the ISO C3 envelope
medium
iso-c4-envelope Specifies the ISO C4 envelope
medium
deBry, Hastings, Herriot, Isaacson, Powell [Page 51]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
iso-c5-envelope Specifies the ISO C5 envelope
medium
iso-c6-envelope Specifies the ISO C6 envelope
medium
iso-designated- Specifies the ISO Designated
long-envelope Long envelope medium
na-10x13- Specifies the North American
envelope 10x13 envelope medium
na-9x12-envelope Specifies the North American
9x12 envelope medium
monarch-envelope Specifies the Monarch envelope
na-number-10- Specifies the North American
envelope number 10 business envelope
medium
na-7x9-envelope Specifies the North American
7x9 inch envelope
na-9x11-envelope Specifies the North American
9x11 inch envelope
na-10x14- Specifies the North American
envelope 10x14 inch envelope
na-number-9- Specifies the North American
envelope number 9 business envelope
na-6x9-envelope Specifies the North American
6x9 inch envelope
na-10x15- Specifies the North American
envelope 10x15 inch envelope
The following standard values are defined for the less
commonly used media (white-only):
executive-white Specifies the white executive
medium
folio-white Specifies the folio white
medium
invoice-white Specifies the white invoice
medium
ledger-white Specifies the white ledger
medium
quarto-white Specified the white quarto
medium
iso-a0-white Specifies the ISO A0 white
medium
iso-a1-white Specifies the ISO A1 white
medium
iso-a2-white Specifies the ISO A2 white
medium
deBry, Hastings, Herriot, Isaacson, Powell [Page 52]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
iso-a6-white Specifies the ISO A6 white
medium
iso-a7-white Specifies the ISO A7 white
medium
iso-a8-white Specifies the ISO A8 white
medium
iso-a9-white Specifies the ISO A9 white
medium
iso-10-white Specifies the ISO A10 white
medium
iso-b0-white Specifies the ISO B0 white
medium
iso-b1-white Specifies the ISO B1 white
medium
iso-b2-white Specifies the ISO B2 white
medium
iso-b3-white Specifies the ISO B3 white
medium
iso-b6-white Specifies the ISO B6 white
medium
iso-b7-white Specifies the ISO B7 white
medium
iso-b8-white Specifies the ISO B8 white
medium
iso-b9-white Specifies the ISO B9 white
medium
iso-b10-white Specifies the ISO B10 white
medium
jis-b0-white Specifies the JIS B0 white
medium
jis-b1-white Specifies the JIS B1 white
medium
jis-b2-white Specifies the JIS B2 white
medium
jis-b3-white Specifies the JIS B3 white
medium
jis-b6-white Specifies the JIS B6 white
medium
jis-b7-white Specifies the JIS B7 white
medium
jis-b8-white Specifies the JIS B8 white
medium
jis-b9-white Specifies the JIS B9 white
medium
jis-b10-white Specifies the JIS B10 white
medium
deBry, Hastings, Herriot, Isaacson, Powell [Page 53]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
The following standard values are defined for engineering
media:
a Specifies the engineering A
size medium
b Specifies the engineering B
size medium
c Specifies the engineering C
size medium
d Specifies the engineering D
size medium
e Specifies the engineering E
size medium
The following standard values are defined for input-trays
(from ISO DPA and the Printer MIB):
top The top input tray in the printer.
middle The middle input tray in the printer.
bottom The bottom input tray in the printer.
envelope The envelope input tray in the
printer.
manual The manual feed input tray in the
printer.
large- The large capacity input tray in the
capacity printer.
main The main input tray
side The side input tray
The following standard values are defined for media sizes
(from ISO DPA):
iso-a0 Specifies the ISO A0 size: 841 mm by
1189 mm as defined in ISO 216
iso-a1 Specifies the ISO A1 size: 594 mm by 841
mm as defined in ISO 216
iso-a2 Specifies the ISO A2 size: 420 mm by 594
mm as defined in ISO 216
iso-a3 Specifies the ISO A3 size: 297 mm by 420
mm as defined in ISO 216
iso-a4 Specifies the ISO A4 size: 210 mm by 297
mm as defined in ISO 216
iso-a5 Specifies the ISO A5 size: 148 mm by 210
mm as defined in ISO 216
iso-a6 Specifies the ISO A6 size: 105 mm by 148
mm as defined in ISO 216
deBry, Hastings, Herriot, Isaacson, Powell [Page 54]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
iso-a7 Specifies the ISO A7 size: 74 mm by 105
mm as defined in ISO 216
iso-a8 Specifies the ISO A8 size: 52 mm by 74
mm as defined in ISO 216
iso-a9 Specifies the ISO A9 size: 37 mm by 52
mm as defined in ISO 216
iso-a10 Specifies the ISO A10 size: 26 mm by 37
mm as defined in ISO 216
iso-b0 Specifies the ISO B0 size: 1000 mm by
1414 mm as defined in ISO 216
iso-b1 Specifies the ISO B1 size: 707 mm by
1000 mm as defined in ISO 216
iso-b2 Specifies the ISO B2 size: 500 mm by 707
mm as defined in ISO 216
iso-b3 Specifies the ISO B3 size: 353 mm by 500
mm as defined in ISO 216
iso-b4 Specifies the ISO B4 size: 250 mm by 353
mm as defined in ISO 216
iso-b5 Specifies the ISO B5 size: 176 mm by 250
mm as defined in ISO 216
iso-b6 Specifies the ISO B6 size: 125 mm by 176
mm as defined in ISO 216
iso-b7 Specifies the ISO B7 size: 88 mm by 125
mm as defined in ISO 216
iso-b8 Specifies the ISO B8 size: 62 mm by 88
mm as defined in ISO 216
iso-b9 Specifies the ISO B9 size: 44 mm by 62
mm as defined in ISO 216
iso-b10 Specifies the ISO B10 size: 31 mm by 44
mm as defined in ISO 216
na-letter Specifies the North American letter
size: 8.5 inches by 11 inches
na-legal Specifies the North American legal
size: 8.5 inches by 14 inches
executive Specifies the executive size (7.25 X
10.5 in)
folio Specifies the folio size (8.5 X 13
in)
invoice Specifies the invoice size (5.5 X
8.5 in)
ledger Specifies the ledger size (11 X 17
in)
quarto Specifies the quarto size (8.5 X
10.83 in)
deBry, Hastings, Herriot, Isaacson, Powell [Page 55]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
iso-c3 Specifies the ISO C3 size: 324 mm by
458 mm as defined in ISO 269
iso-c4 Specifies the ISO C4 size: 229 mm by
324 mm as defined in ISO 269
iso-c5 Specifies the ISO C5 size: 162 mm by
229 mm as defined in ISO 269
iso-c6 Specifies the ISO C6 size: 114 mm by
162 mm as defined in ISO 269
iso- Specifies the ISO Designated Long
designated size: 110 mm by 220 mm as defined in
-long ISO 269
na-10x13- Specifies the North American
envelope 10x13 size: 10 inches by 13
inches
na-9x12- Specifies the North American
envelope 9x12 size: 9 inches by 12 inches
na-number-10- Specifies the North American
envelope number 10 business envelope
size: 4.125 inches by 9.5 inches
na-7x9- Specifies the North American 7x9
envelope inch envelope size
na-9x11- Specifies the North American
envelope 9x11 inch envelope size
na-10x14- Specifies the North American
envelope 10x14 inch envelope size
na-number-9- Specifies the North American
envelope number 9 business envelope size
na-6x9- Specifies the North American 6x9
envelope envelope size
na-10x15- Specifies the North American
envelope 10x15 envelope size
monarch- Specifies the Monarch envelope
envelope size (3.87 x 7.5 in)
a Specifies the engineering A
size: 8.5 inches by 11
inches
b Specifies the engineering B
size: 11 inches by 17
inches
c Specifies the engineering C
size: 17 inches by 22
inches
d Specifies the engineering D
size: 22 inches by 34
inches
deBry, Hastings, Herriot, Isaacson, Powell [Page 56]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
e Specifies the engineering E
size: 34 inches by 44
inches
jis-b0 Specifies the JIS B0 size: 1030mm x
1456mm
jis-b1 Specifies the JIS B1 size: 728mm x
1030mm
jis-b2 Specifies the JIS B2 size: 515mm x
728mm
jis-b3 Specifies the JIS B3 size: 364mm x
515mm
jis-b4 Specifies the JIS B4 size: 257mm x
364mm
jis-b5 Specifies the JIS B5 size: 182mm x
257mm
jis-b6 Specifies the JIS B6 size: 128mm x
182mm
jis-b7 Specifies the JIS B7 size: 91mm x 128mm
jis-b8 Specifies the JIS B8 size: 64mm x 91mm
jis-b9 Specifies the JIS B9 size: 45mm x 64mm
jis-b10 Specifies the JIS B10 size: 32mm x 45mm
5.2.5.2 number-up (type3Enum)
5.2.5.2.1 As a Job Attribute
This job attribute specifies the number of source page-
images to impose upon a single side of an instance of a
selected medium.
5.2.5.2.2 As a Printer Attribute
This printer attribute identifies the default value and
the number-up values supported by this printer..
The state of readiness for each number-up value is also
included, though all number-up conversions should always
be ready.
In general, only certain numeric values are valid for
this attribute and the value "none", depending upon the
Printer implementation to which the print-request is
directed. Standard values are: "none", "1", "2", "4".
deBry, Hastings, Herriot, Isaacson, Powell [Page 57]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
This attribute primarily controls the translation,
scaling and rotation of page images, but a site may
choose to add embellishments, such as borders to each
logical page. The value "none" shall not include any
embellishments and shall place one logical page on a
single side of an instance of the selected medium without
any translation, scaling, or rotation.
5.2.5.3 sides (type2 keyword)
5.2.5.3.1 As a Job Attribute
This job attribute specifies how source page-images are
to be imposed upon the sides of an instance of a selected
medium.
When this attribute appears as a job attribute with the
embedded tag, it may contain more than one value and it
shall indicate all sides operations required by the
document.
5.2.5.3.2 As a Printer Attribute
This printer attribute indicates the default. It also
indicates the values of the sides attribute supported by
this printer and the states of readiness of each value.
The standard values are: 1-sided, 2-sided-long-edge, 2-
sided-short-edge.
1-sided imposes each consecutive source page-image upon
the same side of consecutive media sheets.
2-sided-long-edge imposes each consecutive pair of source
page-image upon front and back sides of consecutive media
sheets, such that the orientation of each pair of source-
pages on the medium would be correct for the reader as if
for binding on the long edge. This imposition is
sometimes called "duplex".
2-sided-short-edge imposes each consecutive pair of
source page-image upon front and back sides of
consecutive media sheets, such that the orientation of
each pair of source-pages on the medium would be correct
deBry, Hastings, Herriot, Isaacson, Powell [Page 58]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
for the reader as if for binding on the short edge. This
imposition is sometimes called "tumble" or "head-to-toe".
2-sided-long-edge and 2-sided-short-edge work the same
for portrait or landscape. That is, "head-to-toe" is
"tumble" in portrait but "duplex" in landscape. "head-
to-head" also switches between "duplex" and "tumble" when
using portrait and landscape modes.
5.2.5.4 printer-resolution (type2 keyword)
5.2.5.4.1 As a Job Attribute
This job attribute specifies the resolution that the
Printer should use.
When this attribute appears as a job attribute with the
embedded tag, it shall indicate the printer resolution
required by the document.
5.2.5.4.2 As a Printer Attribute
This printer attribute indicates the default value. It
also indicates the values of the printer-resolution-
select attribute supported by this printer and their
states of readiness.
The state of readiness for each printer resolution is
also included, though normally all printer-resolutions
should always be ready.
The values are type2Enums which represent single integers
or pair of integers. The latter are to specify the
resolution when the x and y dimensions differ. When two
integers are specified, the first is in the x direction,
i.e., in the direction of the shortest dimension of the
medium, so that the value is independent of whether the
printer feeds long edge or short edge first.
The standard values are:
res-100
res-200
res-240
res-300
deBry, Hastings, Herriot, Isaacson, Powell [Page 59]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
res-600
res-800
res-1200
res-1800
res-100x200
res-300x600
res-600x300
res-400x800
res-800x400
res-600x1200
res-1200x600
res-1800x600
5.2.5.5 print-quality (type2 keyword)
5.2.5.5.1 As a Job Attribute
This job attribute specifies the print quality that the
Printer should use.
When this attribute appears as a job attribute with the
embedded tag, it shall indicate the print-quality
required by the document.
5.2.5.5.2 As a Printer Attribute
This printer attribute indicates the default value. It
also indicates the values of the printer-quality
attribute supported by this printer and the states of
readiness for each print-quality value.
The standard values are defined in the printer-quality
attribute.
The standard values are:
draft Lowest quality available on the
printer
normal Normal or intermediate quality on
the printer
high Highest quality available on the
printer
deBry, Hastings, Herriot, Isaacson, Powell [Page 60]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.2.5.6 copies (integer(1:2**31 - 1))
5.2.5.6.1 As a Job Attribute
This job attribute specifies the number of copies of the
job to be printed.
NOTE - The effect of this attribute on jobs and documents
is controlled by the multiple-files-are job attribute.
5.2.5.6.2 As a Printer Attribute
This printer attribute indicates the default value. It
also specifies the minimum and maximum number of copies
of a document that can be rendered by this printer in a
single print-job.
5.2.5.7 finishing (setOf type2 keyword)
5.2.5.7.1 As a Job Attribute
This job attribute identifies the finishing operation
that the Printer should apply to each copy of each
printed document in the job where the definition of a
copy is controlled by the multiple-documents-are Job
attributes.
When this attribute appears as a job attribute with the
embedded tag, it may contain more than one value and it
shall indicate all finishing operations required by the
job.
5.2.5.7.2 As a Printer Attribute
This printer attribute identifies the default value. It
also identifies the finishing operations supported by
this Printer and states of availability for each
finishing.
Standard values for this attribute are:
none Perform no finishing.
deBry, Hastings, Herriot, Isaacson, Powell [Page 61]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
staple This indicates that staples are to
be used to bind the document. The
exact number and placement of the
staples is site-defined; other
finishing object attributes may be
included to provide this
information.
staple-top- This indicates that one or more
left staples should be placed on the top
left corner of the document
staple- This indicates that one or more
bottom-left staples should be placed on the
bottom left corner of the document
staple-top- This indicates that one or more
right staples should be placed on the top
right corner of the document
staple-
bottom- staples should be placed on the
This indicates that one or more
right bottom right corner of the document
saddle- This indicates that one or more
stitch staples (wire stitches) are to be
used to bind the document along the
middle fold. The exact number and
placement of the stitches is site-
defined.
edge-stitch This indicates that one or more
staples (wire stitches) are to be
used to bind the document along one
edge. The exact number and
placement of the staples is site-
defined.
punch This indicates that holes are
required in the finished document.
The exact number and placement of
the holes is site-defined The
punch specification may be
satisfied (in a site- and
implementation-specific manner)
either by drilling/punching, or by
substituting predrilled media.
cover This value is specified when it is
desired to select a non-printed (or
pre-printed) cover for the
document. This does not supplant
the specification of a printed
cover (on cover stock medium) by
the document itself.
deBry, Hastings, Herriot, Isaacson, Powell [Page 62]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
bind This indicates that a binding is to
be applied to the document; the
type and placement of the binding
is site-defined.
5.2.5.8 compression (type2 keyword)
This attribute identifies compression algorithms used for
compression document data.
Standard values for this attribute are: zip, tar, ...
5.2.5.8.1 As a Job Attribute
This job attribute identifies the compression algorithm
that has been applied to the document data.
5.2.5.8.2 As a Printer Attribute
This printer attribute identifies the default value. It
also identifies the compression algorithms supported by
this Printer
5.2.6 Document Format Attributes (Set by Client/End User)
There is no group name for these attributes since there
is only one attribute in the group.
5.2.6.1 document-format (type2 keyword)
5.2.6.1.1 As a Job Attribute
This job attribute identifies the document format of this
document, and may be a per-document attribute.
5.2.6.1.2 As a Printer Attribute
This printer attribute indicates default value. It also
indicates the values of the attribute supported by this
deBry, Hastings, Herriot, Isaacson, Powell [Page 63]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
printer and the states of readiness for each value. One
possible supported and default value is "auto-sense".
The following standard values have been reviewed with the
Printer Working Group and are registered with IANA as
part of the IETF Printer MIB project. The standard value
assigned by the PWG starts with the four letters: "lang",
in order to follow SNMP ASN.1 rules that all enum symbols
shall start with a lower case letter. The keyword values
in IPP shall be the same as the PWG standard values
registered with IANA with the "lang" removed. The MIB
(integer) value is included here for reference only, the
MIB integer value shall not be used in IPP; the keyword
value shall be used instead:
keyword MIB Description
Value val
ue
other 1
PCL 3 PCL. Starting with PCL version 5,
HP-GL/2 is included as part of the
PCL language. PCL and HP-GL/2 are
registered trademarks of Hewlett-
Packard Company.
HPGL 4 Hewlett-Packard Graphics Language.
HP-GL is a registered trademark of
Hewlett-Packard Company.
PJL 5 Peripheral Job Language. Appears
in the data stream between data
intended for a page description
language. Hewlett-Packard Co.
PS 6 PostScript Language (tm)
Postscript - a trademark of Adobe
Systems Incorporated which may be
registered in certain
jurisdictions
IPDS 7 Intelligent Printer Data Stream
Bi-directional print data stream
for documents consisting of data
objects (text, image, graphics,
bar codes), resources (fonts,
overlays) and page, form and
finishing instructions.
Facilitates system level device
control, document tracking and
error recovery throughout the
print process. Pennant Systems,
IBM
deBry, Hastings, Herriot, Isaacson, Powell [Page 64]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
PPDS 8 IBM Personal Printer Data Stream.
Originally called IBM ASCII, the
name was changed to PPDS when the
Laser Printer was introduced in
1989. Lexmark International, Inc.
EscapeP 9 Epson Corp.
Epson 10
DDIF 11 Digital Document Interchange
Format Digital Equipment Corp.,
Maynard MA
Interpress 12 Xerox Corp.
ISO6429 13 ISO 6429. Control functions for
Coded Character Sets (has ASCII
control characters, plus
additional controls for character
imaging devices.) ISO Standard,
Geneva, Switzerland
LineData 14 line-data: Lines of data as
separate ASCII or EBCDIC records
and containing no control
functions (no CR, LF, HT, FF,
etc.). For use with traditional
line printers. May use CR and/or
LF to delimit lines, instead of
records. See ISO 10175 Document
Printing Application (DPA) ISO
standard, Geneva, Switzerland
MODCA 15 Mixed Object Document Content
Architecture Definitions that
allow the composition,
interchange, and presentation of
final form documents as a
collection of data objects (text,
image, graphics, bar codes),
resources (fonts, overlays) and
page, form and finishing
instructions. Pennant Systems,
IBM
REGIS 16 Remote Graphics Instruction Set,
Digital Equipment Corp., Maynard
MA
SCS 17 SNA Character String Bi-
directional print data stream for
SNA LU-1 mode of communications
IBM
SPDL 18 ISO 10180 Standard Page
Description Language ISO Standard
TEK4014 19 Tektronix Corp.
deBry, Hastings, Herriot, Isaacson, Powell [Page 65]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
PDS 20
IGP 21 Printronix Corp.
CodeV 22 Magnum Code-V, Image and printer
control language used to control
impact/dot- matrix printers. QMS,
Inc., Mobile AL
DSCDSE 23 DSC-DSE: Data Stream Compatible
and Emulation Bi-directional print
data stream for non-SNA (DSC) and
SNA LU-3 3270 controller (DSE)
communications IBM
WPS 24 Windows Printing System, Resource
based command/data stream used by
Microsoft At Work Peripherals.
Developed by the Microsoft
Corporation.
LN03 25 Early DEC-PPL3, Digital Equipment
Corp.
CCITT 26
QUIC 27 QUIC (Quality Information Code),
Page Description Language for
laser printers. Included
graphics, printer control
capability and emulation of other
well- known printer . QMS, Inc.
CPAP 28 Common Printer Access Protocol
Digital Equipment Corp
DecPPL 29 Digital ANSI-Compliant Printing
Protocol (DEC-PPL) Digital
Equipment Corp
SimpleText 30 simple-text: character coded data,
including NUL, CR , LF, HT, and FF
control characters. See ISO 10175
Document Printing Application
(DPA) ISO standard, Geneva,
Switzerlan
NPAP 31 Network Printer Alliance Protocol
(NPAP). This protocol has been
superseded by the IEEE 1284.1
TIPSI standard. (ref.
LangTIPSI(49)).
DOC 32 Document Option Commands, Appears
in the data stream between data
intended for a page description .
QMS, Inc
imPress 33 imPRESS, Page description language
originally developed for the
ImageServer line of systems. A
deBry, Hastings, Herriot, Isaacson, Powell [Page 66]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
binary language providing
representations for text, simple
graphics (rules, lines, conic
sections), and some large forms
(simple bit-map and CCITT group
3/4 encoded).The language was
intended to be sent over an 8-bit
channel and supported early
document preparation languages
(e.g. TeX and TROFF). QMS, Inc.
Pinwriter 34 24 wire dot matrix printer for
USA, Europe, and Asia except
Japan. More widely used in
Germany, and some Asian countries
than in US. NEC
NPDL 35 Page printer for Japanese market.
NEC
NEC201PL 36 Serial printer language used in
the Japanese market. NEC
Automatic 37 Automatic PDL sensing. Automatic
sensing of the interpreter
language family by the printer
examining the document content.
Which actual interpreter language
families are sensed depends on the
printer implementation.
Pages 38 Page printer Advanced Graphic
Escape Set IBM Japan
LIPS 39 LBP Image Processing System
TIFF 40 Tagged Image File Format (Aldus)
Diagnostic 41 A hex dump of the input to the
interprete
PSPrinter 42 The PostScript Language used for
control (with any PDLs) Adobe
Systems Incorporated
CaPSL 43 Canon Print Systems Language
EXCL 44 Extended Command Language Talaris
Systems Inc
LCDS 45 Line Conditioned Data Stream Xerox
Corporatio
XES 46 Xerox Escape Sequences Xerox
Corporation
PCLXL 47 Printer Control Language.
Extended language features for
printing, and printer control.
Technical reference manual # TBD.
Hewlett-Packard Co.
ART 48 Advanced Rendering Tools (ART).
deBry, Hastings, Herriot, Isaacson, Powell [Page 67]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Page Description language
originally developed for the Laser
Press printers. Tehnical
reference manual: "ART IV
Reference Manual", No F33M. Fuji
Xerox Co., Ltd.
TIPSI 49 Transport Independent Printer
System Interface (ref. IEEE Std.
1284.1)
Prescribe 50 Page description and printer
control language. It can be
described with ordinary ASCII
characters. Technical reference
manual: "PRESCRIBE II Programming
Manual"
LinePrinte 51 A simple-text character stream
r which supports the control codes
LF, VT, FF and CR plus Centronics
or Dataproducts Vertical Format
Unit (VFU). language is commonly
used on many older model line and
matrix printers.
IDP 52 Imaging Device Protocol Apple
Computer.
XJCL 53 Xerox Corp.
5.2.7 Job Size (job-size) Attributes (Set by Client and
Printer)
These attributes form the attribute group called "job-
size".
These attribute values all have adornments of either
"total" or "printed" and they indicate the size of a job
in various units. A client may set these attributes, but
not an end-user. The Printer may set these attributes if
the client does not. In both of these cases, the
attribute value has the adornment of "total", which
indicates the client and Printer's best estimate to the
total.
If a value has the adornment of "printed", then the value
shall indicate the current number of octets, impressions
or media-sheets (depending on the attribute) that have
deBry, Hastings, Herriot, Isaacson, Powell [Page 68]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
been printed. Only the printer shall be allowed to set a
value with the "printed" adornment.
If a value has no adornment, then it implicitly has the
adornment "total".
The corresponding Printer attributes indicate the range
of allowed values, but there is no explicit default. If
the Job attribute is not specified and the Printer
attribute is specified, the Printer shall either compute
a value for the job attribute or leave it unspecified.
An attribute is accepted if any one of the following
conditions is satisfied: a) the Printer attribute is
unspecified, b) the job attribute is unspecified, c) the
job attribute is within the range specified by the
Printer attribute.
5.2.7.1 job-k-octets (integer(0:2**31 - 1))
This attribute specifies the total size of the job in K
octets, i.e., in units of 1024 octets. The value shall
be rounded up, so that a job between 1 and 1024 octets
shall be indicated as being 1K, 1025 to 2048 shall be 2,
etc. This attribute is not intended to be a counter as in
the Job Monitoring MIB; it is intended to be useful
routing and scheduling information if known.
5.2.7.1.1 As a Job Attribute
This job attribute is set by client on in the Print
Request if it is known. It is set by the Printer once
the Job object is created if the Printer is able to
calculate this value.
5.2.7.1.2 As a Printer Attribute
This Printer attribute specifies a support range for job
sizes. A default value is not applicable for this
attribute.
deBry, Hastings, Herriot, Isaacson, Powell [Page 69]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.2.7.2 job-impressions (integer(0:2**31 - 1))
This job attribute specifies the total size of the job in
impressions. This attribute is not intended to be a
counter as in the Job Monitoring MIB; it is intended to
be useful routing and scheduling information if known.
5.2.7.2.1 As a Job Attribute
This job attribute is set by client on in the Print
Request if it is known. It is set by the Printer once
the Job object is created if the Printer is able to
calculate this value.
5.2.7.2.2 As a Printer Attribute
This Printer attribute specifies a support range for job
sizes. A default value is not applicable for this
attribute.
5.2.7.3 job-media-sheets (integer(0:2**31 - 1))
This job attribute specifies the total size of the job in
media-sheets. This attribute is not intended to be a
counter as in the Job Monitoring MIB; it is intended to
be useful routing and scheduling information if known.
5.2.7.3.1 As a Job Attribute
This job attribute is set by client on in the Print
Request if it is known. It is set by the Printer once
the Job object is created if the Printer is able to
calculate this value.
5.2.7.3.2 As a Printer Attribute
This Printer attribute specifies a support range for job
sizes. A default value is not applicable for this
attribute.
deBry, Hastings, Herriot, Isaacson, Powell [Page 70]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.2.8 Number of Documents (Set by Printer)
This group contains a single attribute which specifies
the number of documents in the job.
This group does not have a name since there is only one
attribute in the group.
The client need not set this attribute because, the
Printer sets the value of this job attribute depending on
the number of documents that the client supplies in the
Print operation. The client may specify this attribute
in: Get-Attributes and Get-Jobs.
The printer attribute is set by an implementation and
contains the range of values supported. Normally, it is
either exactly 1 document or at least 1 document. The
printer shall reject a job if the number of documents is
not in the range of this attribute.
5.2.8.1 number-of-documents (integer(1:2**31 - 1))
This attribute specifies the number of documents in the
job. There are document specific attributes (see section
5.4).
5.3 Job Attributes Set by the Printer
These attributes form the attribute group called "job-
set-by-printer".
The Printer sets the value for each of these job
attributes. A client may not set them.
5.3.1 Job Identification (job-identification) Attributes
(Set by the Printer)
These attributes form the attribute group called "job-
identification".
5.3.1.1 job-URL (url)
This attribute contains the URL for the job.
deBry, Hastings, Herriot, Isaacson, Powell [Page 71]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
The Printer, on receipt of a new job, shall generate a
URL which identifies the job on the Printer. The Printer,
shall return the value of the URL job attribute as part
of the PrintResult in the Print operation. The precise
format of a job URL shall be implementation dependent.
5.3.2 Job Owner (job-owner) Attributes (Set by a Printer)
The Print shall add all of these attributes to a job to
provide information to identify a print-job.
These attributes form the attribute group called "job-
owner".
The client may specify these attributes in the
operations: Get-Attributes and Get-Jobs, but not in
Print.
5.3.2.1 job-originating-user (name)
This attribute specifies the user name of the person
submitting the print job. The Printer shall set this
attribute to the most authentic name that it can obtain
from the protocol over which the operation was received
from the client.
5.3.2.2 job-originating-host (name)
This attribute identifies the originating host of the
job. The Printer shall set this attribute to the most
authentic host name it can obtain from the protocol over
which the operation was received from the client.
5.3.2.3 user-locale (type3 keyword)
This attribute identifies the locale of the job, i.e, the
country, language, and coded character set. The Printer
sets this attribute the most authentic value it can
obtain from the protocol over which the operation was
received from the client..
The Printer shall use this attribute to determine the
locale for notification messages that it sends.
deBry, Hastings, Herriot, Isaacson, Powell [Page 72]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
Issue: Is there a more standard syntax for locale?
The standard values are listed under the document-locale
attribute.
ISSUE: specify the list of valid locales.
5.3.2.4 job-name (name)
This attribute contains the name of the job. It is a
name that is more user friendly than the job-URL. The
Printer, on receipt of the job, shall generate a name
which is the name of the first document in the job. This
name comes from the document-name or document-URL
depending on which attribute is specified.
5.3.3 Job Status (job status) Attributes (Set by Printer)
These attributes form the attribute group called "job-
status".
The Printer shall add these attributes to a job when a
client submits a job, and the Printer shall assign
appropriate values to each such job-status attribute.
The Printer uses these attributes to specify the job
status before, during and after the processing of the
print-job by the Printer.
The client may specify job-status attributes in: Get-
Attributes and Get-Jobs, but not Print.
5.3.3.1 job-state (type1 keyword)
This attribute identifies the current state of the job.
Standard values are:
unknown The job state is not known, or is
indeterminate.
pending The job is waiting to start processing
on a printer. Various job-reasons may
keep a job from moving to the printing
state.
deBry, Hastings, Herriot, Isaacson, Powell [Page 73]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
processing The server is processing the job, or
has made the job ready for printing,
but the output device is not yet
printing it, either because the job
hasn't reached the output device or
because the job is queued in the
output device or some other spooler,
awaiting the output device to print
it.
Or
The server has completed processing
the job and the output device is
currently printing the job. That is,
an output device is either printing
pages of the job, or failing in its
attempt to print pages of the job
because of some wait state, such as,
start-wait, end-wait, needs-attention,
etc. The complete job state includes
the detailed status represented in the
printer's printer-state attribute.
As with the printer state, let's let
the reason make the distinction as to
whether paper is being marked or the
printer is just processing. Most
printers won't bother with this
nuance.
terminatin The job has been canceled by a Cancel-
g Job request or aborted by the server
and is in the process of terminating.
The job's job-state-reasons attribute
contains the reasons that the job is
being terminated.
deBry, Hastings, Herriot, Isaacson, Powell [Page 74]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
retained The job is being retained at the
server. The job has (1) completed
successfully or with warnings or
errors, (2) been aborted while
printing by the server, or (3) been
canceled by the Cancel-Job request
before or during processing. The
job's job-state-reasons attribute
contains the reasons that the job has
been retained.
While in the retained state, all of
the job's document data (and
resources, if any) shall be retained
by the server; thus a job in the
retained state could be reprinted,
using some means outside the scope of
IPP V1.0. If a given implementation
does not support this functionality,
there is no need to support this
value.
deBry, Hastings, Herriot, Isaacson, Powell [Page 75]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
completed The job has:
(1) completed successfully or with
warnings or errors,
(2) been aborted by the server
while printing, or
(3) been canceled by the Cancel-
Job request,
For case 1, "completed " only happens
when all job media sheets have been
properly stacked in the appropriate
output tray or bin.
The job's job-state-reasons attribute
contains the reason(s) that the job
has been completed.
While in the completed state, a job's
document data (and resources if any)
need not be retained by the server;
thus a job in the completed state
could not be reprinted. The length of
time that a job may be in this state,
before transitioning to unknown, is
implementation-dependent. However,
servers that implement the completed
job-state shall retain, as a minimum,
the following attributes for any job
in the completed state: job-
identifier, job-originator, job-name,
current-job-state, output-device-
assigned, and job-state-reasons.
The IPP protocol supports all values for job states, but
Printers need only support those states which are
appropriate for the particular implementation.
5.3.3.2 job-state-reasons (setOf type2 keyword)
This attribute identifies the reason or reasons that the
job is in the state that it is in (e.g., held,
terminating, retained, completed, etc.). The printer
shall indicate the particular reason(s) by setting the
value of the job-state-reasons attribute.
ISSUE: Should we change job-incomplete to job-spooling
and adde job-queued, job-sent-to-printer and job-held?
Job-queued is really the default. Job-held can only be
deBry, Hastings, Herriot, Isaacson, Powell [Page 76]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
changed by an operator in an unspecified manner. Should
a job move to the printing state when a spooler sends it
to a printer or move to the printing state when marking
starts. Should it depend on the printer as to whether it
announces such nuances. We probably need a state
transition diagram.
The following standard values are defined:
job-incomplete The job has been accepted by the
server, but the Printer is
waiting for the transfer of the
remainder of the job.
job-sending-to- Optional. The job is in the
output-device pending state but is being
transmitted to the output device.
job-queued-in- Optional. The job is in the
output-device pending state and is queued on
the output device.
job-printing The job-state is processing, and
the printer is marking media.
This attribute is optional and
useful for printers which spend a
great deal of time processing
when no marking is happening.
printer-stopped The printer is stopped. This
reason appears in all jobs in
the pending state when the value
of the Printer's printer-state
attribute is stopped. This reason
appears in a job in the
processing state when the output-
device is stopped.
printer-partly- Optional. This reason appears in
stopped all jobs in the pending state
when the value of the Printer's
printer-state-reasons contains
the value partly-stopped.
job-hold-until- The value of the job's job-hold-
specified until attribute has specified a
time period that has not yet
arrived, so that the Printer
shall not consider the job as a
candidate for processing.
deBry, Hastings, Herriot, Isaacson, Powell [Page 77]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
required- At least one of the resources
resources-not- needed by the job, such as media,
ready fonts, resource objects, etc., is
not ready on any of the physical
printer's for which the job is a
candidate.
successful The job completed successfully.
completion
completed-with- The job completed with warnings.
warnings
completed-with- The job completed with errors
errors (and possibly warnings too).
cancelled-by-user The job was cancelled by the user
using the CancelJob request.
cancelled-by- The job was cancelled by the
operator operator using the CancelJob
request.
aborted-by-system The job was aborted by the
system.
logfile-pending The job's logfile is pending file
transfer.
logfile- The job's logfile is being
transferring transferred.
5.3.3.3 job-state-as-text (text)
This attributes specifies the job-state and job-state-
reasons in human readable text and it shall be set by the
Printer.
5.3.3.4 output-device-assigned (url)
This attribute identifies the Output Device to which the
Printer has assigned this job. It is the printer-URL
rather than the printer-name so that the Output-Device is
not limited to be near the Printer.
If an Output Device implements a Printer, the Printer
need not set this attribute.
If a Print Server implements a Printer, the value shall
be empty until the Printer assigns an Output Device to
the job.
The value of the job's output-device-assigned attribute
shall remain after the job has completed, so that end
deBry, Hastings, Herriot, Isaacson, Powell [Page 78]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
users can determine the Output Device on which the job
was printed.
5.3.3.5 submission-time (dateTime)
This attribute indicates the date and time at which this
job was accepted by the Printer. If the Printer does not
support the notion of time, the attribute need not be
stored as part of the job object.
5.3.3.6 number-of-intervening-jobs (integer(0:2**31 - 1))
This attribute indicates the number of jobs that are
"ahead" of this job in the current scheduled order. For
efficiency, it is only necessary to calculate this value
when an operation if performed that requests this
attribute.
NOTE - This attribute is necessary since an end user may
request just their own jobs and they need some relative
position indicator if there are other jobs interspersed
in the waiting list which are not returned in the
response or cannot be because of site security policy
restrictions.
5.3.3.7 job-message-from-operator (text)
This attribute provides a message from an operator,
system administrator or "intelligent" process to indicate
to the end user the reasons for modification or other
management action taken on a job.
5.3.3.8 completion-time (dateTime)
This attribute indicates the date and time at which this
job completed. This time is useful for jobs which are
retained after printing. If the Printer does not support
the notion of time, the attribute is not stored as part
of the Job object.
deBry, Hastings, Herriot, Isaacson, Powell [Page 79]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.4 Document Attributes
5.4.1 Document Data (document-data) Attributes (Set by a
Client/End User)
These attributes form the attribute group called
"document-data".
This group of attributes describes the document data for
the job. These attributes also include the document data
or reference it.
All job attributes in other sections of this document
occur only once per job and apply to all documents in a
job.
The client may specify document-data attributes in Print.
The client must specify either the document-URL or
document-content in Print.
Except for document-content, the client may specify
document-data attributes in: Get-Attributes, and Get-
Jobs.
5.4.1.1 document-name (name)
This attribute contains the name of the document used by
the client to initially identify the document. If the
client uses a URL, this attribute shall be absent.
ISSUE: Do we need to add a document-file-name attribute
for files that don't have a URL?
5.4.1.2 document-URL (url)
This attribute contains the URL of the document if the
client specified the document with a URL.
If this attribute is specified, then document-content
shall be unspecified.
deBry, Hastings, Herriot, Isaacson, Powell [Page 80]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.4.1.3 document-content (octetString)
This attribute contains the actual contents of the
document.
If this attribute is specified, then document-URL shall
be unspecified.
This attribute shall be used during the transmission of
the Print operation over a network. A Printer shall save
the document data to a file and reference it with the
document-URL. A Get-Attribute or Get-Jobs operation shall
always find that this attribute is unspecified.
5.5 Printer Description (printer-description) Attributes
These attributes form the attribute group called
"printer-description".
5.5.1 Printer Identification (printer-identification
Attributes (Set by the Administrator)
These attributes form the attribute group called
"printer-identification".
5.5.1.1 printer-URL (url)
This attribute contains the URL for the printer.
An administrator shall determine a printer's URL and
shall set this attribute to that URL. The precise format
of a printer URL shall be implementation dependent.
5.5.1.2 printer-name (name)
This attribute contains the name of the printer. It is a
name that is more user friendly than the printer-URL.
An administrator shall determine a printer's name and
shall set this attribute to that name. This name may be
the last part of the printer's URL or it may be
unrelated. In non-US-English locales, a name may contain
characters that are not allowed in a URL.
deBry, Hastings, Herriot, Isaacson, Powell [Page 81]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.5.2 Printer Description Attributes (Set by the
Administrator)
A printer object may be realized in either a Print Server
or Output Device. Note: How these attribute are set by an
Administrator is outside the scope of this specification.
A Printer Object in an Output Device contains a set of
printer object attributes that represent an Output Device
capable of rendering a document in visible form.
Examples include electronic and electro-mechanical
printers such as laser printers, ink-jet printers, and
various kinds of impact printers, but may include other
types of output devices such as microfiche imagers and
plotters as well.
A Printer Object in a Print Server may supply queuing,
spooling, and scheduling for an Output device that does
not queue or spool.
A Print Server, in the most common case, controls exactly
one downstream Output Device. The Print Server's Printer
object has attributes whose values are the same as those
of the Printer object in the downstream Output Device.
A Printer Object in a Print Server may contain a set of
printer object attributes that are the union of the
Printer objects in the downstream Output Devices. This
object extends the capabilities of an Output Device. For
example, an administrator might define a single Print
Server to represent all of the Output Devices of the same
type and capability in a single location, associated with
a particular server. A end user would normally send a
print-job to a Print Server, and allow the Print Server
to assign the job to a particular Output Device based on
the relative load and availability of the printers under
its control, thus providing a load balancing service.
However, nothing precludes an administrator from
configuring a print system so that an end user can send a
print-job directly to an Output Device.
The attributes defined in this section provide
information about a particular Printer.
5.5.2.1 printer-location (text)
This attribute identifies the location of this printer.
deBry, Hastings, Herriot, Isaacson, Powell [Page 82]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.5.2.2 printer-description (text)
This attribute identifies the descriptive information
about the this Printer. This could include things like:
"This printer can be used for printing color
transparencies for HR presentations", or "Out of courtesy
for others, please print only small (1-5 page) jobs at
this printer", or even "this printer is going away on
July 1, 1997, please find a new printer".
5.5.2.3 printer-more-info-site (url)
This attribute contains a URL used to obtain more
information about this specific printer. The
information obtained from this URL is intended for
end-user consumption. Features outside the scope of IPP
can be accessed from this URL. The information is
intended to be specific to this printer instance and site
services. (e.g. job pricing, services offered, end user
assistance) The manufacturer may initially populate this
attribute
5.5.2.4 printer-driver-installer (url)
This attribute contains a URL to use to locate the driver
installer for this printer. This attribute is intended
for consumption by automata. The mechanics of print
driver installation is outside the scope of IPP. The
manufacturer may initially populate this attribute.
5.5.3 Printer Description Attributes (Set by the
Manufacturer)
5.5.3.1 printer-make-and-model (text)
This attribute identifies the make and model of the
printer.
5.5.3.2 maximum-printer-speed (integerUnits)
This attribute indicates the maximum printer speed of the
Printer in units of pages per minute, impressions per
minute, lines per minute, and characters per second. A
deBry, Hastings, Herriot, Isaacson, Powell [Page 83]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
job cannot control a Printer's speed, but a Printer
Browser can use printer speed as a criteria.
The standard units are a type2 setOf keyword : ppm, ipm,
spm, lpm, and cps. These mean pages per minute,
impressions per minutes, sides per minutes, lines per
minute, and characters-per-second, respectively.
5.5.3.3 printer-more-info-manf (url)
This attribute contains a URL used to obtain more
information about this type of printer. The
information obtained from this URL is intended for
end-user consumption. Features outside the scope of IPP
can be accessed from this URL. (e.g. latest firmware,
upgrades, print drivers, optional features available)
The information is intended to be germane to this
printer without regard to site specific modifications or
services.
5.6 Printer Status (printer-status)Attributes
These attributes form the attribute group called
"printer-status".
5.6.1 Printer Status Attributes (Set by the Printer)
5.6.1.1 printer-state (type1 keywordEnum)
This attribute identifies the current state of the
printer. The printer-state reasons attribute augments the
printer-state attribute to give more detailed information
about the printer state.
The protocol shall support all values for printer states.
A Printer shall continually keep this attribute set to
the value in the table below which most accurately
reflects the state of the Printer..
deBry, Hastings, Herriot, Isaacson, Powell [Page 84]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
The following standard values are defined:
unknown The Printer state is not known, or is
indeterminate. A Printer shall use
this state only if it cannot
determine its actual state.
idle If a Printer receives a job (whose
required resources are ready) while
in this state, such a job shall
transit into the processing state
immediately.
If the printer-state-reasons
attribute contains any reasons, they
shall be reasons that would not
prevent a job from transiting into
the processing state immediately,
e.g. is toner-low.
NOTE: if a Printer controls more than
one output device, the above
definition implies that a Printer is
idle if at least one output device is
idle.
processing If a Printer receives a job (whose
required resources are ready) while
in this state, such a job shall
transit into the pending state
immediately. Such a job shall transit
into the processing state only after
jobs ahead of it complete printing.
If the printer-state-reasons
attribute contains any reasons, they
shall be reasons that do not prevent
the current job from printing, e.g.
toner-low.
NOTE: if a Printer controls more than
one output device, the above
definition implies that a Printer is
processing if at least one output
device is processing, and none is
idle.
deBry, Hastings, Herriot, Isaacson, Powell [Page 85]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
stopped If a Printer receives a job (whose
required resources are ready) while
in this state, such a job shall
transit into the pending state
immediately. Such a job shall transit
into the processing state only after
some human fixes the problem that
stopped the printer and after jobs
ahead of it complete printing.
The printer-state-reasons attribute
shall contain at least one reason,
e.g. paper-jam, which prevents it
from either processing the current
job or transiting a pending job to
the processing state.
NOTE: if a Printer controls more than
one output device, the above
definition implies that a Printer is
stopped only if all output devices
are stopped.
NOTE: in the case where a Printer controls more than one
output device, it is tempting to define stopped as when a
sufficient number of output devices are stopped and leave
it to an implementation to define the sufficient number.
But such a rule complicates the definition of stopped
and processing. For example, with this alternate
definition of stopped, a job can move from idle to
processing without human intervention, even though the
Printer is stopped.
5.6.1.2 printer-state-reasons (setOf type2 keyword)
This attribute supplies additional detail about the
printer state.
Each value shall have an adornment to indicate its level
of severity. The three levels are: report (least
severe), warning and error (most severe).
- "report": it has the adornment of "report". An
implementation may choose to omit some or all
reports. Some reports specify finer granularity
about the printer state; others serve as a precursor
deBry, Hastings, Herriot, Isaacson, Powell [Page 86]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
to a warning. A report shall contain nothing that
could affect the printed output.
- "warning": it has the adornment of "warning". An
implementation may choose to omit some or all
warnings. Warnings serve as a precursor to an error.
A warning shall contain nothing that prevents a job
from completing, though in some cases the output may
be of lower quality.
- "error": it has no adornment. An implementation shall
include all errors. If this attribute contains one
or more errors, printer shall be in the stopped
state.
ISSUE: Toner-low should be a warning because it allows
printing to proceed, but in some printers, toner-low may
also produce degraded output. Do we want a fourth
category, perhaps severe-warning which allows a job to
continue printing but with reduced quality?
If a Printer controls more than one output device, each
value of this attribute shall apply to one more of the
output devices. An error on one output device that does
not stop the Printer as a whole appears as a warning in
the Printer's printer-state-reasons attribute. Such a
Printer's printer-state value may be stopped even with no
printer-state-reasons that are errors.
The following standard values are defined:
partly-stopped When a Printer controls more than
one output device, this reason
indicates that one or more output
devices are stopped. If the
reason is a report, fewer than
half of the output devices are
stopped. If the reason is a
warning, fewer than all of the
output devices are stopped.
media-needed A tray has run out of media
paper-jam The printer has a paper jam.
deBry, Hastings, Herriot, Isaacson, Powell [Page 87]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
paused Someone has paused the Printer.
In this state, a Printer shall
not produce printed output, but
it shall perform other operations
requested by a client. If a
Printer had been printing a job
when the Printer was paused, the
Printer shall resume printing
that job when the Printer is no
longer paused and leave no
evidence in the printed output of
such a pause .
shutdown Someone has removed a Printer
from service, and it may be
powered down or physical removed.
In this state, a Printer shall
not produce printed output, and
unless the Printer is realized by
a print server that is still
active, the Printer shall perform
no other operations requested by
a client, including returning
this value. If a Printer had been
printing a job when it was
shutdown, the Printer need not
resume printing that job when the
Printer is no longer shutdown. If
the Printer resumes printing such
a job, it may leave evidence in
the printed output of such a
shutdown, e.g. the part printed
before the shutdown may be
printed a second time after the
shutdown..
connecting-to- The server has scheduled a job on
printer the Printer and is in the process
of connecting to a shared network
output device (and may not be
able to actually start printing
the job for an arbitrarily long
time depending on the usage of
the output device by other
servers on the network).
deBry, Hastings, Herriot, Isaacson, Powell [Page 88]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
timed-out The server was able to connect to
the output device (or is always
connected), but was unable to get
a response from the output device
in the time specified by the
printer's printer-timeout-period
attribute.
stopping The printer will be stopping in a
while and will change its reason
to printer-stopped. This reason
is a non-critical, even for a
Printer with a single output
device. When an output-device
ceases accepting jobs, the
Printer will have this state
while the output device completes
printing.
5.6.1.3 printer-is-accepting-jobs (boolean)
This attribute determines whether the printer is
currently accepting job. If the value is true, the
printer is accepting jobs. If the value is false, the
printer is currently rejecting any jobs submitted to it.
Note: this value is independent of the printer state and
printer-state-reasons because its value does not affect
the current job; rather it affects future jobs. This
attribute may cause the Printer to reject jobs when the
printer-state is idle or it may cause the Printer to
accepts jobs when the printer-state is stopped.
5.6.1.4 printer-state-as-text (text)
This attributes specifies the printer-state, printer-
state-reasons, printer-is-accepting-jobs in human
readable text and it shall be set by the Printer.
When a Printer returns the value of this attribute to a
client, the Printer shall localize the value of this
attribute to be in the locale of the user, as specified
by the Get Attributes or Get Jobs operation.
ISSUE: Give the syntax of this message in English.
deBry, Hastings, Herriot, Isaacson, Powell [Page 89]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
5.6.1.5 queued-job-count (integer(0:2**31 - 1))
This attribute contains a count of the number of jobs
that are either pending and/or processing and shall be
set by the Printer.
5.6.2 Printer Status Attributes (Set by the Administrator)
5.6.2.1 printer-message-from-the-operator (text)
This attribute provides a message from an operator,
system administrator or "intelligent" process to indicate
to the end user information or status of the printer,
such as why it is unavailable or when it is expected to
be available.
5.7 Printer Behavior (printer-behavior) Attributes
These attribute specify the behavior of a printer.
These attributes form the attribute group called
"printer-behavior".
5.7.1 Printer Behavior Attributes (set by the Administrator)
5.7.1.1 printer-locale (locale)
This attribute specifies the locale that the Printer
operates in.
The standard values are defined in the section on the
document-locale attribute.
ISSUE: reference the locales.
5.7.1.2 fonts-substitutions (setOf setOf font)
This attribute specifies an appropriate substitute for a
font that is advertised as supported in the fonts-
supported attribute, even though the Printer doesn't
actually have the font available.
deBry, Hastings, Herriot, Isaacson, Powell [Page 90]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
This attribute consists of a set of font pairs: a font
name and the font to use instead.
If this attribute is unspecified, the Printer does not
perform any font substitutions.
5.7.1.3 scheduling-algorithm (type3 keyword)
This attribute indicates the current scheduling algorithm
for this Printer.
Standard values are: "none", "smallest-job-first", "time-
received".
5.7.1.4 printer-fonts (setOf font)
This attribute specifies what fonts are available at the
Printer or accessible to the Printer. Documents may use
these fonts without requiring that the fonts be
downloaded with the document data.
The standard values are font names.
ISSUE: Should the IPP model include all information that
is currently contained in printer definition files such
as PostScripts printer definition (ppd) files?
6. IANA Considerations
IPP is explicitly designed to be extensible. Additional
attributes can be proposed to be registered by going
through the type 2 or type 3 keyword process which will
register their specification after approval with IANA.
In addition specific implementation instances may support
not only the basic protocol as defined in this
specification, but may add vendor-specific private
extensions by prefixing attribute-names with their
company name registered with IANA for use in domains.
See attribute syntax section. However, such private
extensions shall not duplicate attribute semantics
already in this specification.
deBry, Hastings, Herriot, Isaacson, Powell [Page 91]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
7. Security Considerations
NOTE: There is another Internet-Draft called "Internet
Printing Protocol/1.0: Security." That document is being
drafted and reviewed in parallel with this document.
Before this document can become a formal RFC, any
relevant issues from that document will be rolled into
this one.
A Printer may choose, for security reasons, not to return
all attributes that a client requests. It may even return
none of the requested attributes. In such cases, the
status returned is the same as if the Printer had
returned all requested attributes. The client cannot tell
by such a response whether the requested attribute was
present or absent on the Printer.
8. References
[1] Smith, R., Wright, F., Hastings, T., Zilles, S., and
Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[2] Berners-Lee, T, Fielding, R., and Nielsen, H.,
"Hypertext Transfer Protocol - HTTP/1.0", RFC 1945,
August 1995.
[3] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", RFC 822, August 1982.
[4] Postel, J., "Instructions to RFC Authors", RFC 1543,
October 1993.
[5] ISO/IEC 10175 Document Printing Application (DPA),
Final, June 1996.
[6] Herriot, R. (editor), X/Open A Printing System
Interoperability Specification (PSIS), August 1995.
[7] Kirk, M. (editor), POSIX System Administration -
Part 4: Printing Interfaces, POSIX 1387.4 D8, 1994.
[8] Borenstein, N., and Freed, N., "MIME (Multi-purpose
Internet Mail Extensions) Part One: Mechanism for
Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, September, 1993.
deBry, Hastings, Herriot, Isaacson, Powell [Page 92]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
[9] Braden, S., "Requirements for Internet Hosts -
Application and Support", RFC 1123, October, 1989,
[10] McLaughlin, L. III, (editor), "Line Printer Daemon
Protocol" RFC 1179, August 1990.
[11] Berners-Lee, T., Masinter, L., McCahill, M. ,
"Uniform Resource Locators (URL)", RFC 1738,
December, 1994.
9. Author's Address
Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-4025
EMail: scott_isaacson@novell.com
Tom Hastings
Xerox Corporation
701 S. Aviation Blvd.
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-5514
EMail: hastings@cp10.es.xerox.com
Robert Herriot
Sun Microsystems Inc.
2550 Garcia Ave., MPK-17
Mountain View, CA 94043
Phone: 415-786-8995
Fax: 415-786-7077
Email: robert.herriot@eng.sun.com
Roger deBry
HUC/003G
IBM Corporation
P.O. Box 1900
Boulder, CO 80301-9191
Phone: (303) 924-4080
Fax: (303) 924-9889
Email: debry@vnet.ibm.com
deBry, Hastings, Herriot, Isaacson, Powell [Page 93]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Model and Semantics March 26, 1997
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Web Page: http://www.pwg.org/ipp/
Other Participants:
Devon Taylor, Novell, Inc.
Mike MacKay, Novell, Inc.
Peter Zehler, Xerox, Corp.
Keith Carter, IBM Corporation
Carl-Uno Manros, Xerox, Corp.
Don Wright - Lexmark
Steve Gebert - IBM
Ray Lutz - Cognisys
Mabry Dozier - QMS
Lee Farrell - Canon Information Systems
Hiroyuki Sato - Canon
Pat Nogay - IBM
Jim Walker - Dazel
Jay Martin - Underscore
Bill Wagner - DPI
Stan McConnell - Xerox
Bob Setterbo - Adobe
Randy Turner - Sharp
Rob Whittle - Novell
Ron Bergman - Data Products
Lloyd Young - Lexmark
Andy Davidson - Tektronix
Rick Landau - Digital
David Kellerman - Northlake Software
David Roach - Unisys
Mike Timperman - Lexmark
Chris Wellens - Interworking Labs
Pete Loya - HP
Bob Pentecost - HP
Harry Lewis - IBM
William Wagner - Digital Products
Atsushi Yuki - Kyocera
Rob Rhoads - Intel
Jeff Barnett - IBM
Jim Walker - Dazel
Jeff Copeland - QMS
Chuck Adams - Tektronix
deBry, Hastings, Herriot, Isaacson, Powell [Page 94]
draft-ietf-ipp-model-00.txt, expires September 26, 1997
